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译 者 厅 


一 次 偶然 的 机 会 ， 在 浏览 图 灵 网 站 新 书 的 时 候 ， 无 意 间 发 现 TOP 这 本 书 的 第 二 版 在 招募 译 者 。 之 
前 国内 曾 引 进 此 书 ， 作 为 Oracle 性 能 调 优 领 域 的 里 程 碑 式 著作 ， 这 本 书 给 了 国内 DBA 许 多 的 启发 。 因 
此 发 现 此 书 的 第 二 版 之 后 ， 当 即 决定 了 翻译 意向 ， 随 后 在 与 编辑 联系 并 试 译 通过 以 后 ， 即 开始 了 翻译 
工作 。 此 书 原版 共 700 余 页 , 我 在 开始 翻译 之 后 马上 就 感觉 到 了 压力 ， 所 以 就 联系 了 同 为 DBA 的 朋友 、 
本 人 进入 Oracle 领 域 的 引路 人 刘 迪 ， 请 他 帮忙 分 担 一 部 分 翻译 工作 。 

此 书 从 Oracle 调 优 基础 讲 起 ， 介 绍 了 如 何 定位 性 能 问题 ， 同 时 对 查询 优化 器 的 工作 原理 进行 了 详 
细 描 述 ， 最 后 总 结 了 一 些 常见 的 调 优 技 术 。 作 者 对 Oracle 调 优 技术 的 细节 把 挖 方面 令 译 者 深 感 敬佩 ， 
其 严谨 的 态度 也 是 译 者 以 及 广大 DBA 从 业者 学 习 的 榜样 。 在 此 ， 译 者 感谢 原著 作者 的 辛苦 付出 。 

此 书 第 1、2、6、7、8、9、10、14、15、16 章 以 及 文 前 部 分 由 王 作 佳 翻译 , 第 3、4、5、11、12、 
13 章 由 刘 迪 翻译 。 

此 书 在 翻译 过 程 中 有 很 多 名 词 术语 , 译 者 尽量 全 部 翻译 ， 遇 到 表达 不 准 的 术语 时 ， 均 尽力 采用 网 
络 上 常见 的 翻译 ， 另 外 多 数 不 常 见 的 术语 译 者 都 标注 了 原文 以 供 读者 参考 。 此 书 为 译 者 第 一 部 译作 ， 
因 译 者 水 平 有 限 以 及 书 中 涉及 技术 较 深 , 再 加 之 译 者 时 间 有 限 , 难免 有 误 译 漏 译 现象 , 还 请 读者 见谅 。 
如 有 发 现 错误 ， 请 通过 译 者 邮箱 或 图 灵 网 站 联系 以 便 修 正 。 

在 此 感谢 图 灵 公 司 的 编辑 朱 强 老师 ， 她 给 了 我 许多 指导 和 帮助 。 同 时 感谢 图 灵 其 他 编辑 老师 为 本 
书 付出 的 辛苦 努力 。 在 翻译 初期 , 我 的 同事 史 盈盈 女士 给 出 了 许多 宝贵 的 建议 , 在 此 表示 感谢 。 另外， 
感谢 数据 库 组 的 同事 们 在 翻译 期 间 给 予 的 理解 和 帮助 。 


王 作 性 
感谢 我 的 团队 在 翻译 期 间 给 予 的 理解 与 支持 。 感 谢 王 作 佳 提供 的 这 次 翻译 机 会 ， 让 我 受益 良 多 。 
感谢 妻子 孙 婷 的 照顾 与 理解 ， 能 让 我 有 时 间 专 心 翻译 。 感 谢 图 灵 的 各 位 编辑 对 本 书 付出 的 努力 。 


刘 迪 
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在 为 本 书写 序言 的 时 候 ， 我 在 阅读 完 样 章 后 ， 做 的 第 一 件 事 就 是 查看 我 为 第 一 版 写 的 序言 ， 看 看 
其 中 有 多 少 内 容 需 要 改动 。 显 然 ， 参 考 的 章节 号 是 需要 修改 的 。 但 令 我 吃惊 的 是 ， 在 关于 为 什么 有 志 
向 的 Oracle 专 业 人 士 都 应 该 读 读 这 本 书 的 问题 上 ， 有 几 个 重要 的 观点 我 没 能 讲 清楚 。 借 此 修订 序言 之 
机 ， 我 进一步 阐述 如 下 。 

互联 网 上 充斥 着 关于 Oracle 的 众多 信息 ， 但 是 这 些 信息 是 高 度 碎片 化 的 ， 吸 需 整理 和 提炼 。 许 多 
已 出 版 的 Oracle 书 籍 也 都 存在 同样 的 问题 : 书 中 提供 了 大 量 的 信息 ,但 没有 按照 任何 形式 的 逻辑 体系 
进行 讲述 ， 这 使 得 读者 很 难 抓 住 一 个 主题 ， 也 就 无 法 作为 后 续 学 习 和 理解 的 切入 点 。 其 至 ，Oracle 官 
方 手册 也 存在 同样 的 问题 ,但 情况 相对 较 好 一 些 。 在 性 能 诊断 的 演示 中 我 经 常 阐述 的 观点 是 ,在 你 的 
阅读 清单 中 应 该 包含 以 下 三 本 Oracle 官 方 手册 : Oracle Database Concepts 手册 、Oracle Database 
Administrator % Guide 和 Oracle Database Performance Tuning Guide。 然 而 ， 在 阅读 任意 一 本 手册 时 ， 你 
会 发 现 ， 其 中 一 些 知识 直到 读 完 其 他 两 本 之 后 才能 真正 理解 。 本 书 的 一 大 特色 正 是 它 在 组 织 信息 的 方 
式 上 避免 了 上 述 历史 问题 ， 明 确 告诉 我 们 需要 达成 的 目的 是 什么 ， 为 什么 要 达成 这 些 目的 ， 以 及 如 何 
达成 这 些 目 的 。 

有 时 ， 这 种 结构 简单 得 令 人 难以 置信 。 我 就 被 书 中 相 邻 三 章 的 标题 所 吸引 ， 且 不 说 这 些 章节 的 内 
容 非 常 值得 阅读 ， 仅 就 标题 而 言 ， 已 经 对 某 些 概念 进行 了 异常 清晰 的 阐述 ,将 其 长 久未 被 认识 到 的 重 
要 性 凸显 出 来 ， 它 们 正 是 在 性 能 诊断 过 程 中 应 当 首 先 注意 的 问题 : 

口 第 3 章 分 析 可 重 现 问题 

口 第 4 章 实时 分 析 不 可 重 现 问题 

口 第 5 章 事后 分 析 不 可 重 现 问题 

你 是 否 意识 到 问题 的 类 型 只 有 三 种 ,而 你 解决 问题 的 策略 往往 又 取决 于 这 三 类 中 的 哪 一 类 ? 在 所 
有 的 案例 中 ,用 来 解决 问题 的 数据 的 基本 来 源 都 是 一 样 的 ， 但 随 着 时 间 的 推移 ， 某 些 数据 的 可 用 性 和 
粒度 会 发 生变 化 。 因 此 ， 理 解 这 种 问题 分 类 是 系统 化 解决 问题 的 第 一 步 。 

整 本 书 都 以 一 种 相同 的 架构 进行 论述 : 整理 各 种 信息 , 并 展示 各 种 可 能 性 以 及 如 何 获取 相应 结果 。 
例如 , 第 6 章 列 举 了 一 长 串 Oracle 优 化 查询 时 可 能 执行 的 转换 ,第 13 章 则 给 出 了 一 个 很 长 的 列表 ， 展示 
可 能 出 现在 执行 计划 中 基于 分 区 操作 的 不 同方 法 。 

待 读 完 本 书后 ， 你 可 能 会 发 现 ， 学 到 的 知识 比 想象 的 要 多 很 多 ; 而 对 于 本 来 已 经 知晓 的 知识 ， 由 
于 分 散 的 知识 点 被 整合 到 了 一 起 ， 空 白 点 得 以 补充 完善 ， 如 今 又 有 了 更 深入 的 理解 。Christian 的 知识 
和 见解 已 然 让 信息 重 构 了 ! 

一 一 Jonathan Lewis 
世界 级 Oracle 专 家 ， 《Oracle 核 心 技术 》 作 者 
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在 过 去 十 年 间 ， 我 认为 在 Oracle 性 能 领域 最 令 人 欣慰 的 情形 是 : 如 今 ， 在 书店 买 到 的 书籍 中 所 承 
载 的 信息 质量 有 了 根本 性 的 改善 。 

从 前 能 买 到 的 关于 Oracle 性 能 方面 的 书籍 几乎 如 出 一 纹 。 这 些 书 不 是 在 暗示 你 的 Oracle 系 统 必然 承 
载 了 太 多 的 IO ( 事实 上 并 不 一 定 )， 就 是 提 到 没有 足够 的 内 存 ( 就 像 上 一 种 说 辞 一样 ， 也 不 是 真实 情 
况 ), 它们 可 能 会 堆砌 罗列 大 量 你 可 能 会 运行 的 SQL 语 句 , 并 让 你 优化 这 些 SQL, 声称 这 样 可 以 解决 一 
切 性 能 问题 。 

那 是 一 个 黑暗 的 时 代 。 

Chris 的 这 本 书 就 是 刺 破 这 黑暗 的 光明 使 者 之 一 。 黑暗 和 光明 的 差别 可 归结 为 一 种 简单 的 理念 , 一 
种 从 你 10 岁 起 数学 老师 就 让 你 反复 实践 的 理念 : 演示 你 的 做 法 。 

我 的 意思 并 非 “ 展 示 并 介绍 "， 就 像 有 人 声称 让 一 个 拥有 数 百 用户 的 站 点 提升 了 百 分 之 几 百 的 性 
能 ( 原 话 就 是 这 样 说 的 )， 然 后 自封 为 专家 。 我 所 说 的 演示 你 的 做 法 ， 是 指 先 记录 一 个 相关 的 基线 测 
量 , 再 进行 一 次 受 控 实验 ， 记 录 男 一 个 基线 测量 ,然后 公开 透明 地 公布 你 的 结果 ， 让 读者 可 以 跟随 你 
的 思路 甚至 在 需要 时 重 现 你 的 案例 。 : 

这 一 点 很 重要 。 当 作者 们 开始 那样 做 时 ，Oracle 爱 好 者 们 就 会 受益 匪 浅 。 从 2000 年 开始 ， 在 Oracle 
社区 中 提出 深层 次 性 能 问题 并 寻求 高 品质 答案 的 人 明显 增加 了 许多 。 这 也 使 得 人 们 更 迅速 地 剔除 那些 
曾 被 许多 人 信服 的 错误 方法 。 

本 书 中 ，Chris 遵 循 了 有 效 的 模式 。 他 向 你 讲述 有 用 的 技术 。 但 不 止 于 此 ， 他 还 介绍 自己 是 如 何 知 
道 这 些 技术 的 ， 换 句 话 讲 ， 他 告诉 你 如 何 自己 找 出 问题 答案 。Chris 演 示 了 他 的 做 法 。 

这 样 做 有 两 个 益处 。 首 先 ， 能 让 你 更 深入 地 理解 他 所 演示 的 内 容 ， 从 而 更 容易 记 住 和 应 用 他 的 课 
程 。 其 次 , 通过 理解 这 些 例子 , 你 不 仅 可 以 理解 Chris 正 在 演示 给 你 的 内 容 ， 同 时 还 能 够 解决 Chris 没 有 
提 及 的 其 他 有 意思 的 问题 ， 比 如 像 本 书 付 印 后 Oracle 的 下 一 个 版 本 会 出 现 哪些 新 特性 。 

对 我 而 言 , 这 本 书 是 兼 具 技 术 性 与 指导 性 的 参考 手册 , 它 包含 了 大 量 文档 化 的 可 重用 的 作业 案例 。 
本 书 也 包含 几 个 有 说 服 力 的 新 论据 , 使 我 可 以 分 享 Chris 的 观点 和 热忱 。Chris 在 此 书 中 使 用 的 论据 可 以 
帮 我 说 服 更 多 的 人 正确 地 做 事 。 

Chris 不 仅 容 智 而 且 精 力 充 沛 ， 他 站 在 了 一 些 Oracle 专 家 的 肩 上 ,这些 人 包括 : Dave Ensor、Lex de 
Haan、Anjo Kolk、Steve Adams 、Jonathan Lewis 、Tom Kyte， 等 等 。 这 些 人 都 是 我 心中 的 英雄 ， 正 是 
他 们 为 这 个 领域 带 来 严谨 之 风 。 现 在 ,我 们 也 可 以 站 在 Chris 的 肩 上 了 。 

——Cary Millsap 
Method R 公 司 首 席 执 行 官 ， 博 客 地 址 http://carymillsap.blogspot.com。 
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我 从 20 多 年 前 开始 使 用 Oracle 数 据 库 软件 , 大概 花 了 3 年 时 间 才 发 现 , 在 人 们 看 来 ,问题 诊断 和 调 
优 简直 神秘 得 不 可 思议 。 

曾经 有 个 开发 人 员 发 给 DBA 团 队 一 条 性 能 不 好 的 查询 语句 。 我 检查 了 执行 计划 和 数据 样本 ,然后 
指出 大 部 分 的 工作 量 可 以 通过 给 其 中 的 一 张 表 添加 一 条 索引 来 消除 。 开 发 人 员 的 回答 是 :“ 这 是 张 小 
表 ， 并 不 需要 索引 啊 。”( 当时 是 6.0.36 版 本 的 时 代 ， 顺 便 提 一 下 ， 那 时 小 表 的 定义 是 “不 超过 四 个 块 
的 大 小 ”。) 最 终 我 还 是 创建 了 索引 ， 查 询 速 度 提升 了 30 倍 ， 当 然 我 又 有 一 大 堆 要 解释 的 内 容 。 

问题 诊断 并 不 依赖 于 魔法 、 秘 诀 或 神话 ,更 多 的 是 依靠 理解 、 观 察 和 解释 。 理 查 德 : 费 曼 曾 说 过 : 
“无 论 你 的 理论 有 多 完美 ， 还 是 你 有 多 聪明 ， 如 果 称 的 理论 和 实验 结论 不 符 ， 那 这 理论 就 是 错误 的 ,” 
在 Oracle 性 能 方面 有 许多 这 样 错 误 的 “理论 ”, 多 年 以 前 就 应 该 从 集体 认 知 中 清除 掉 , Christian Antognini 
就 是 一 个 能 帮 你 消除 错误 理论 的 人 。 

在 本 书 中 ，Christian 着 手 描述 事情 真正 的 工作 方式 ， 你 应 该 留意 什么 样 的 症状 ， 以 及 这 些 症状 代 
表 什么 含义 。 另 外 , 尤其 难能可贵 的 是 ， 他 还 鼓励 你 要 有 条 不 紊 地 去 进行 观察 与 分 析 ， 并 密切 关注 过 
程 中 出 现 的 相关 细节 。 有 了 这 个 建议 ， 你 就 能 够 在 出 现 性 能 问题 时 以 最 合适 的 方法 定位 出 真正 的 症结 
所 在 。 

尽管 这 本 书 很 可 能 需要 你 从 头 至 尾 仔仔 细 细 地 阅读 , 但 是 不 同 的 读者 应 该 会 以 不 同 的 方式 从 中 获 
益 。 有 些 人 可 能 偶尔 在 浏览 时 发 现 一 些 独到 的 见解 ,正如 我 此 前 多 年 一 直 搞 不 懂 高 度 均 衡 直方 图 为 何 
如 此 命名 ， 而 直到 读 了 第 4 章 后 ，Christian 的 描述 才 让 我 茅 塞 顿 开 。 

一 些 读者 会 找到 一 些 特性 的 简短 描述 帮助 他 们 理解 Oracle 为 什么 要 实现 这 些 特性 ， 并 让 他 们 通 
过 案例 推导 与 他 们 的 应 用 相关 联 的 情形 。 第 5 章 关 于 “安全 视图 合并 ”的 描述 对 于 我 来 说 就 是 这 样 。 

男 一 部 分 读者 可 能 会 屡次 重复 阅读 本 书 中 的 某 一 章节 ,因为 这 一 章节 含有 他 们 正在 使 用 的 某 些 重 
要 特性 的 许多 细节 。 我 想 第 9 章 中 关于 分 区 的 深入 讨论 就 会 让 人 们 孜孜 不 倦 地 反复 阅读 。 

本 书 内 容 丰 富 ， 值 得 仔细 研读 。 谢 谢 你 ，Christian。 


Jonathan Lewis 


第 二 版 致谢 


面 对 现 实 吧 ， 写 书 并 不 是 一 件 值 得 去 做 的 事 。 根 本 不 值 ! 写 书 会 占用 你 很 多 的 业余 时 间 , 用 这 些 
时 间 你 本 可 以 做 些 更 有 趣 的 事情 。 所 以 当 我 决定 是 否 应 该 着 手写 本 书 第 二 版 的 时 候 ， 我 反复 问 自己 ， 
为 什么 要 继续 写 呢 ? 最 终 , 决定 动笔 最 重要 的 因素 是 我 从 2008 年 第 一 版 出 版 后 陆续 收 到 的 数 以 百 计 的 
正面 留言 。 我 发 现 ， 出 版 一 本 书 时 得 到 大 家 的 肯定 就 是 一 种 回报 ! 就 冲 这 一 点 ， 最 应 该 感谢 的 是 那些 
读 完 第 一 版 后 给 了 我 反馈 的 读者 。 没 有 你 们 给 我 动力 ， 第 二 版 也 不 会 存在 了 。 

当然 写 一 本 书 只 有 动力 还 不 行 。 之 前 提 过 ， 写 书 牵扯 大 量 的 时 间 。 在 这 方面 我 是 幸运 的 ， 我 所 在 
的 Trivadis 公 司 ( 我 从 1999 年 人 职 该 公司 ) 给 了 我 全 力 支 持 ，Trivadis 不 仅 让 我 自身 的 技术 得 到 提升 ， 
同时 还 鼓励 我 追求 那些 并 非 总 有 绝对 把 握 的 事情 ( 比如 写 书 )。 所 以 第 二 个 感谢 应 该 送 给 Trivadis 公 司 。 

当 你 集中 精力 写 一 段 文字 超过 一 定 的 时 间 ， 有 时 会 忽视 一 些 显 而 易 见 的 事情 。 基 于 这 一 点 ,我 得 
说 身边 有 几 个 人 时 常 帮 你 检查 你 的 工作 是 非常 重要 的 。 谨 在 此 向 技术 评审 人 Alberto 、Franco 和 Joze 致 
以 诚挚 的 谢意 , 是 你 们 帮 有 我 极 大 地 改进 了 本 书 的 质量 。 当 然 , 若 有 其 他 不 足 和 错误 都 是 我 自己 的 责任 。 
除了 几 位 “官方 的 "技术 评审 人 以 外 ,还 要 感谢 Dani Schnider Franck Pachot、 Randolf Geist 和 Tony Hasler 
等 人 ， 他 们 在 阅读 本 书 某 些 部 分 后 给 出 了 宝贵 的 评论 和 见解 。 

还 要 感谢 Apress 的 工作 人 员 在 本 书 创作 过 程 中 给 予 的 支持 。 尤 其 感谢 Jonathan Gennick ， 他 坚持 认 
为 创作 第 二 版 是 明智 的 选择 。 

和 第 一 版 一 样 , 本 书 出 版 的 另 一 个 核心 人 物 是 Curtis Gautschi。 实 际 上 ， 他 再 一 次 协助 我 校对 了 全 
书 , 尽管 他 并 不 能 完全 理解 他 读 到 的 内 容 ( 据 他 声称 )。 非常 感谢 你 ，Curtis， 这 么 多 年 来 一 直 帮 助 我 。 

最 后 ， 特 别 感谢 Jonathan 和 Cary 为 表示 支持 而 为 本 书 作 序 。 你 们 在 我 职业 生涯 起 步 时 激励 了 我 ， 
如 今 希 望 本 书 可 以 激励 更 多 Oracle 社 区 中 的 人 做 出 正确 的 事情 。 


第 一 版 致谢 


许多 人 协助 我 写 出 了 你 手中 的 这 本 书 。 我 由 囊 地 感激 他 们 。 没 有 他 们 的 帮助 ， 这 部 作品 就 不 会 有 
机 会 面世 。 请 允许 我 在 跟 各 位 分 享 这 本 书 的 简 史 时 ， 感 谢 成 就 这 一 切 的 人 们 。 

虽然 当时 我 并 没有 意识 到 ， 但 此 书 的 写作 与 出 版 历程 始 于 2004 年 7 月 16 日 ， 当 时 我 正在 为 一 个 叫 
作 “Oracle 优 化 解决 方案 ”的 研讨 会 召开 启动 会 议 ， 与 几 个 Trivadis 的 同事 计划 写 一 些 材料 。 在 会 上 ， 
我 们 讨论 了 研讨 会 的 目标 和 结构 。 那 天 以 及 随后 几 个 月 写 下 的 研讨 材料 中 产生 的 想法 都 用 在 了 本 书 
中 。 非 常 感谢 当时 与 Arturo Guadagnin、Dominique Duay 和 Peter Welker 的 合作 。 我 们 当时 一 起 写 下 的 
研讨 材料 ， 相 信 以 今天 的 眼光 来 看 也 是 一 流 的 。 除 了 他 们 几 个 ,我 还 要 感谢 Guido Schmutz， 他 虽然 只 
参加 了 启动 会 议 ， 却 强烈 影响 了 我 们 处 理 研 讨 会 中 涉及 的 主题 的 方式 方法 。 

2006 年 春天 ， 也 就 是 两 年 以 后 ， 我 开始 认真 考虑 要 写 这 本 书 。 我 当时 决定 联系 在 Apress 工 作 的 
Jonathan Gennick， 告 诉 他 我 的 想法 并 征询 他 的 意见 。 从 一 开始 ， 他 就 对 我 的 提议 很 感 兴趣 ， 所 以 仅仅 
几 个 月 后 , 我 就 决定 将 来 在 Apress 出 版 此 书 。 谢 谢 你 ，Jonathan， 从 一 开始 就 支持 我 。 此 外 , 感谢 所 有 
为 此 书 成 功 付 梓 而 付出 心血 的 Apress 员 工 。 我 个 人 有 地 与 Sofia Marchant 、Kim Wimpsett 和 Laura 
Esterman 合 作 ， 但 我 知道 还 有 其 他 很 多 人 也 同样 做 出 了 贡献 。 

有 了 想法 和 出 版 商 并 不 足以 写 出 一 本 书 , 你 还 需要 时 间 , 大 量 的 时 间 。 幸 运 的 是 ,我 的 公司 Trivadis 
支持 并 允许 我 花费 时 间 在 此 书 的 创作 上 。 在 这 里 尤其 要 感谢 Urban Lankes 和 Valentin De Martin。 

当 你 写作 时 周围 有 人 帮 你 仔细 检查 写 下 的 内 容 也 是 至 关 重 要 的 。 非 常 感谢 Alberto Dell"Era 、 
Francesco Renne 、Joze Senegacnik 和 Urs Meier 这 几 位 技术 评审 人 ， 他 们 为 帮助 此 书 提高 质量 做 出 颇 多 
贡献 。 当 然 ， 如 有 其 他 遗留 问题 都 是 我 的 责任 。 除 技术 评审 外 ,我 还 要 感谢 Daniel Rey 、Peter Welker、 
Philipp vondem Bussche-Hiinnefeld 及 Rainer Hartwig， 他 们 在 阅读 了 本 书 部 分 内 容 后 给 出 了 宝贵 的 评论 
和 见解 。 

此 书 出 版 的 另 一 个 核心 人 物 是 Curtis Gautschi。 多 年 来 ， 都 是 他 帮忙 校对 并 提高 了 我 糟糕 的 英语 。 
太 感 谢 你 了 ，Cnurtis， 帮 助 了 我 这 么 多 年 。 我 承认 ， 某 一 天 我 真得 加 强 一 下 英语 技能 了 。 不 过 ， 我 发 
现 改进 基于 Oracle 应 用 程序 的 性 能 比 学 外 语 更 有 意思 ( 也 更 容易 )。 

在 这 里 特别 感谢 Cary Millsap 和 Jonathan Lewis 为 本 书 作 序 。 我 知道 这 占 去 了 你 们 很 多 宝贵 的 时 间 ， 
非常 感激 二 位 。 

同时 特别 感谢 Grady Booch 人 允许 我 在 第 1 章 中 使 用 他 的 漫画 。 

最 后 , 我 要 感谢 这 些 年 我 有 幸 当 过 顾问 的 公司 ,感谢 所 有 那些 参加 了 我 的 课程 和 研讨 会 并 提出 很 
多 好 问题 的 人 ， 感 谢 那 些 分 享 知识 的 Trivadis 顾 问 。 我 从 你 们 所 有 人 当中 获 益 良 多 。 
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Oracle 数 据 库 已 经 成 长 为 超大 型 软件 。 这 不 仅 意味 着 仅 赁 一 已 之 力 不 再 能 够 精通 新 版 本 提供 的 所 
有 特性 ， 同 时 也 表明 有 一 些 特性 很 少 会 用 到 。 实 际 上 ， 在 大 多 数 情况 下 ， 能 够 掌握 并 利用 其 中 一 部 分 
核心 特性 就 足以 高 效 、 成 功 地 使 用 Oracle 数 据 库 。 所 以 在 本 书 中 ， 我 根据 经 验 ， 仅 挑选 出 那些 在 诊断 
数据 库 相 关 性 能 问题 时 必然 要 用 到 的 特性 。 


组 织 结构 


本 书 分 为 四 个 部 分 。 

第 一 部 分 涵盖 了 阅读 本 书 剩余 部 分 所 需 的 基础 知识 。 第 1 章 不 仅 解释 了 为 什么 一 定 要 在 正确 的 时 
间 使 用 正确 的 方法 处 理性 能 问题 ， 还 说 明了 为 什么 一 定 要 了 解 业务 需求 和 问题 所 在 。 这 一 章 也 撒 述 了 
由 数据 库 相关 设计 问题 引发 的 一 些 常见 的 性 能 不 佳 的 情况 。 第 2 章 描述 了 数据 库 引 擎 在 解析 和 执行 
SQL 语句 时 所 执行 的 操作 ， 以 及 如 何 检测 应 用 程序 代码 和 数据 库 调用 。 另 外 ， 这 一 章 也 介绍 了 本 书 中 
常用 的 一 些 重要 术语 。 

第 二 部 分 解释 了 如 何在 使 用 Oracle 数 据 库 的 环境 中 处 理性 能 问题 。 第 3 章 描述 如 何 借助 SQL 跟踪 和 
PL/SQL 探 查 器 识别 性 能 问题 。 第 4 章 描述 如 何 利 用 动态 性 能 视图 提供 的 信息 ， 同 时 还 将 介绍 几 个 经 党 
与 动态 性 能 视图 一 起 使 用 的 工具 和 技术 。 第 5 章 描述 如 何 借助 自动 工作 负载 存储 库 AWR 和 Statspack 来 
分 析 之 前 发 生 的 性 能 问题 。 

第 三 部 分 描述 负责 将 SQL 语句 生成 执行 计划 的 组 件 :查询 优化 器 。 第 6 章 概述 了 查询 优化 器 的 功 
能 及 其 实现 方式 。 第 7 章 和 第 8 章 描述 什么 是 系统 统计 信息 和 对 象 统计 信息 ， 如 何 收集 统计 信息 ， 以 及 
统计 信息 对 于 查询 优化 器 的 重要 性 。 第 9 章 讲述 如 何 通过 配置 路 线 图 为 查询 优化 器 制定 合理 的 配置 。 
第 10 章 描述 获得 、 解 释 执行 计划 和 评估 执行 计划 效率 所 需 了 解 的 细节 知识 。 

第 四 部 分 展示 了 Oracle 数 据 库 为 高 效 执行 SQL 语句 提供 的 特性 。 第 11 章 描述 了 如 何 通过 Oracle 数 据 
库 提供 的 相关 技术 去 影响 查询 优化 器 生成 执行 计划 。 第 12 章 描述 了 如 何 识别 、 解 决 以 及 排除 由 解析 引 
发 的 性 能 问题 。 第 13 章 描述 访问 数据 的 多 种 方法 以 及 如 何在 其 中 选择 合适 的 。 第 14 章 讨论 如 何 高 效 联 
接 多 个 数据 集 。 第 15 章 描述 类 似 并 行 处 理 、 物 化 视图 和 结果 集 缓存 这 样 的 高 级 调 优 技术 。 第 16 章 解释 
为 什么 优化 数据 库 的 物理 设计 如 此 重要 。 


目标 读者 


本 书 的 目标 读者 是 那些 因 在 应 用 程序 中 使 用 了 Oracle 数 据 库 而 涉及 诊断 性 能 问题 的 性 能 专家 、 应 


2 引 


用 程序 开发 人 员 和 数据 库 管理 员 。 

本 书 不 需要 某 些 具体 的 优化 方面 的 知识 。 但 是 ,希望 读者 具有 Oracle 数 据 库 相关 的 应 用 知识 并 熟 
练 掌握 SQL。 本 书 某 些 章节 会 涉及 关于 具体 的 编程 语言 ( 如 PL/SQL、Java、C#、PHP 以 及 C 等 ) 的 一 
些 特性 。 之 所 以 提 及 这 些 特性 ， 仅 是 为 了 照顾 不 同 的 应 用 开发 人 员 在 使 用 不 同 的 编程 语言 时 所 体现 的 
信息 差异 ， 你 可 以 挑选 自己 正在 使 用 的 或 者 感 兴趣 的 语言 。 


涵盖 哪些 版 本 


本 书 涉及 的 大 部 分 重要 概念 都 不 依赖 于 你 所 使 用 的 Oracle 数 据 库 版 本 。 然 而 不 可 避免 地 ， 当 讨论 
具体 的 实现 细节 时 ， 某 些 内 容 是 与 版 本 相关 的 。 本 书 主要 讨论 的 是 目前 可 用 的 版 本 ,包括 从 Oracle 
Database 10g R2 至 Oracle Database 12c R1， 如 下 所 示 。 

口 Oracle Database 10g R2， 包 含 的 版 本 至 10.2.0.5.0 

口 Oracle Database 11gR1， 包 含 的 版 本 至 11.1.0.7.0 

口 Oracle Database 11g R2， 包 含 的 版 本 至 11.2.0.4.0 

口 Oracle Database 12c R1， 版 本 12.1.0.1.0 

注意 ， 粒 度 是 补丁 集 (patch set ) 级 别 ， 因 此 ， 本 书 不 讨论 安全 补丁 和 捆绑 补丁 (bundle patch” ) 
所 带 来 的 变化 。 如 果 没 有 明确 说 明 某 一 特性 仅 适 合 某 一 特定 版 本 ， 那 么 它 对 所 有 提 到 的 版 本 都 有 效 。 


在 线 资 源 


可 以 在 网 站 http://top.antognini.ch 上 下 载 本 书 引用 的 文件 ， 也 可 以 在 其 中 找到 勘误 和 补充 资料 。 
男 外 ， 如 果 有 关于 本 书 的 任何 类 型 的 反馈 意见 或 问题 ， 请 发 送 到 top@antognini.ch。 


与 第 一 版 的 不 同 之 处 


本 书 修订 的 主要 目标 包括 以 下 各 项 。 

口 增加 关于 Oracle Database 11g R2 和 Oracle Database 12c R1 的 内 容 。 

口 删 掉 关 于 Oracle Database 97 和 Oracle Database 10g R1 的 内 容 。 

口 补 上 第 一 版 遗漏 的 内 容 ， 例 如 层次 剖析 工具 、 活 动 会 话 历 史 (ASH )、AWR 及 Statspack 等 。 
口 当 涉及 具体 的 编程 语言 特性 时 加 入 一 些 有 关 PHP 的 知识 。 

口 为 提高 可 读 性 重新 组 织 了 部 分 素材 ， 例 如 ， 将 系统 和 对 象 统 计 信 息 拆 分 为 两 章 。 

口 修复 勘误 ， 改 进行 文 组 织 。 


中， 一 种 临时 补丁 ,包含 许多 重要 的 bug 修 复 , 但 是 没有 PSU 多 ， 主 要 供 Windows 平 台 使 用 。 这 里 指示 考虑 小 版 本 号 差 
异 ， 如 10.2.0.5.6 或 10.2.0.5.12。 一 一 译 者 注 
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Chi non fa e fondamenti Prima, gli potrebbe con una grande virt lt poi, ancora che si faccino 
con disagio dello architettore e periculo dello edifizio. 


一 个 人 如 果 没 有 先 打 好 基础 ， 于 所 朱 有 可 能 用 基 起 的 能 力 过 各国， 但 这 对 于 建筑 
师 来 说 很 困 难 ， 对 于 建筑 物 来 说 也 很 危险 。 


一 一 尼 科 洛 : 马 基 和 雅 维 利 , 《君主 论 》，1532 年 


@ 英文 版 由 W. K. Marriott 翻译 ， 链 接地 址 : http://www.gutenberg.org/files/1232/1232-h/1232-h.htm。 


太 多 时 候 ， 优 化 工作 在 应 用 程序 开发 结束 以 后 才 开始 。 这 种 做 法 是 不 可 取 的 ， 因 为 它 会 导致 人 们 
以 为 性 能 并 不 像 应 用 程序 的 其 他 关键 需求 那样 重要 。 人 性 能 并 不 只 是 应 用 程序 的 一 种 可 选 指标 ， 而 是 一 
个 关键 指标 。 糟 糕 的 性 能 不 仅 有 损 应 用 程序 的 可 接受 程度 ， 而 且 通 常 还 会 降低 用 户 的 工作 效率 ,导致 
投资 回报 率 较 低 。IBM 在 20 世 纪 80 年 代 早期 所 做 的 多 项 研究 表明 ， 应 用 程序 的 性 能 与 用 户 的 工作 效率 
有 着 密切 的 关系 : 系统 处 理事 务 的 效率 越 低 ， 用 户 的 思考 时 间 就 会 越 长 ， 发 生 错误 的 概率 就 会 越 高 ， 
这 是 用 户 长 时 间 等 待 之 后 注意 力 下 降 的 必然 结果 。 此 外 ， 性 能 糟糕 的 应 用 程序 还 往往 导致 更 高 的 软件 
成 本 、 人 硬件 成 本 及 维护 成 本 。 基 于 上 述 原因 ， 本 章 将 主要 讨论 为 何 性 能 规划 如 此 重要 ,哪些 是 最 常见 
的 导致 性 能 欠 佳 的 设计 失误 ， 以 及 如 何 知 道 一 个 应 用 程序 出 现 了 性 能 问题 。 而 后 ， 本 章 将 讨论 出 现 性 
能 问题 时 该 如 何 进行 处 理 。 


1.1 需要 为 性 能 做 规划 吗 


在 软件 工程 领域 ， 用 于 管理 项 目 开发 的 模型 各 式 各 样 ; 不 管 是 类 似 瀑布 模型 的 顺序 型 生命 周期 ， 
还 是 类 似 敏 捷 开发 的 迭代 型 生命 周期 ， 都 需要 经 历 几 个 共同 阶段 ( 见 图 1-1 )。 在 项目 开 发 过 程 中 ， 这 
些 阶 段 可 能 只 出 现 一 次 〈 如 瀑布 模型 )， 也 可 能 出 现 多 次 ( 如 迭代 模型 )。 


ptr) no) ae 


图 1-1 应 用 程序 开发 的 主要 阶段 


如 果 仔 细 分 析 以 上 每 个 阶段 所 需 开展 的 工作 ， 你 也 许 会 注意 到 每 个 阶段 都 有 性 能 要 求 。 即 便 如 此 ， 
在 实际 开发 过 程 中 , 开发 团队 还 是 会 时 常 忘记 性 能 要 求 , 直到 性 能 问题 浮现 出 来 。 而 那 时 也 许 为 时 已 晚 。 
因此 ， 本 章 接 下 来 的 部 分 将 从 性 能 的 角度 出 发 ， 介 绍 在 下 一 次 开发 应 用 程序 时 不 应 该 再 忽视 的 内 容 。 


1.1.1 需求 分 析 


简单 来 讲 ， 需 求 分 析 ( requirements analysis ) 就 是 确定 应 用 程序 的 主要 目标 以 及 闽 此 期 望 达 成 的 
目的 。 进 行 需求 分 析 之 前 ,通常 要 对 多 个 利益 相关 方 进行 调研 。 这 一 步 十 分 必要 ， 因 为 单独 一 方 不 太 
可 能 确定 所 有 的 业务 需求 和 技术 需求 。 由 于 需求 的 来 源 不 一 ， 因 此 必须 对 需求 进行 仔细 分 析 ， 尤 其 需 


1.1 需要 为 性 能 做 规划 吗 3 


要 找 出 不 同 需求 间 是 否 存在 潜在 冲突 。 在 进行 需求 分 析 时 ,不仅 要 关注 应 用 程序 需要 提供 的 功能 ， 仔 
细 确 定 这 些 功 能 的 使 用 率 也 是 至 关 重要 的 。 对 于 每 一 个 具体 的 功能 , 需要 预 估 与 之 交互 的 用 户 数量 、 
用 户 的 使 用 频率 以 及 每 次 使 用 时 的 预期 响应 时 间 。 换 句 话 说 ， 你 必须 确定 预期 的 性 能 指标 。 


响应 时 间 

从 请 求 进入 系统 或 者 功能 单元 到 其 离开 的 时 间 间 隔 叫 作 响应 时 间 (responsetime )。 响 应 时 间 可 
以 进一步 分 解 为 服务 时 间 ( service time ) ( 系统 处 理 请 求 所 需 时 间 ) 和 等 待 时 间 ( wait time ) ( 请 求 
等 待 处 理 的 时 间 )。 等 待 时间 在 排队 论 中 又 称 为 排队 延迟 ( queueing delay )。 

响应 时 间 = 服 务 时 间 + 等 待 时 间 

如 果 考 虑 到 用 户 在 执行 动作 (例如 单 击 某 个 按钮 ) 时 某 个 请 求 进入 系统 ， 而 用 户 在 收 到 系统 对 
于 这 个 动作 所 做 出 的 相应 反应 时 该 请 求 离开 系统 ,之 间 的 这 段 时 间 间 隔 可 以 叫 作 用 户 响应 时 间 。 换 
句 话 讲 ， 用 户 响应 时 间 是 指 从 用 户 角 度 来 计算 的 处 理 一 个 请 求 所 需 的 时 间 。 

有 些 情况 下 ， 如 Web 应 用 ， 一 般 不 考虑 用 户 响 应 时 间 ， 因 为 在 请 求 抵达 应 用 程序 的 第 一 个 组 件 
(通常 是 网 络 服务 器 ) 之 前 一 般 无 法 对 它们 进行 跟踪 。 此 外 ， 大 多 数 情况 下 保证 用 户 响 应 时 间 是 不 
可 能 的 ， 因 为 应 用 程序 提供 商 并 不 负责 用 户 程序 (通常 是 浏览 器 ) 与 系统 程序 第 一 个 组 件 之 间 的 网 
络 。 此 时 ,测量 并 保证 从 请 求 进入 系统 的 第 一 个 组 件 到 离开 的 时 间 间 隔 更 为 合理 。 这 一 时 间 间 隔 称 
为 系统 响应 时 间 。 

| 

表 1-1 是 由 JPetStore” 提供 的 一 些 操 作 的 预期 性 能 数据 样 例 。 对 于 每 项 操作 ， 该 表 给 出 了 系统 对 于 
收 到 的 90% 和 99.99% 的 请 求 所 能 保证 的 系统 响应 时 间 。 多 数 情况 下 ,要 保证 系统 对 于 所 有 请 求 ( 即 100% 
的 请 求 ) 的 性 能 ， 要么 不 可 能 ,要么 需要 高 额 投 入 。 所 以 ,最 常见 的 做 法 是 指明 一 小 部 分 请 求 可 能 无 
法 达到 所 需 的 响应 时 间 。 由 于 系统 负载 随 日 常 运行 发 生变 化 ， 因 此 该 表 用 两 个 值 来 表示 最 大 到 达 率 。 
本 例 中 ， 最 高 的 事务 率 预 计 出 现在 白天 。 但 在 其 他 情况 下 ， 例 如 将 批量 作业 放 在 夜间 进行 时 ， 可 能 会 
有 所 不 同 。 


表 1-1 由 某 网 络 商店 提供 的 典型 操作 的 性 能 数据 


操作 类 型 最 长 响应 时 间 〈 秒 ) 最 大 到 达 率 (事务 数 /分 钟 ) 

90% 99.99% 0~7 8~23 
注册 /修改 个 人 资料 2 5 | 2 
登录 /退出 0.5 1 5 20 
检索 商品 1 2 60 240 
显示 商品 概览 1 2 30 120 
显示 商品 细节 1:8 3 10 36 
从 购物 车 添加 /更 改 / 移 除 商 品 1 2 4 12 


中 注意 : 这 里 的 “用 户 ” 并 不 总 是 指 人 。 举 个 例子 ， 如 果 你 正在 定义 一 个 网 络 服务 需求 ， 很 可 能 它 的 “用 户 ” 只 是 
其 他 应 用 程序 。 
@ JPetStore 是 由 Spring Framework 等 提供 的 一 个 示例 应 用 程序 。 登 录 可 下 载 或 获取 更 多 信息 
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( 续 ) 
操作 类 型 人 最 大 到 达 率 《事务 娄 / 分 钊 ) 
90% 99.99% 0~7 8-23 
显示 购物 车 1 | 8 32 
提交 /确认 订单 1 2 3 , 


这 些 性 能 需求 不 仅仅 作为 核心 要 素 贯 穿 于 应 用 程序 开发 的 各 个 阶段 ( 见 后 面 几 节 )， 稍 后 也 可 将 
其 作为 定义 服务 级 别 协议 以 及 制定 容量 规划 的 基础 。 


服务 级 别 协议 

服务 级 别 协议 (SLA ) 是 用 来 明确 服务 提供 商 和 用 户 之 间 关 系 的 契约 。 它 描述 的 内 容 包括 服务 
项 目 ， 其 在 运行 时 间 和 停机 时 间 的 可 用 性 、 响 应 时 间 、 客 户 支持 水 平 ， 以 及 一 旦 服务 提供 商 无 法 履 
行 协议 时 相应 的 处 理 方式 。 

只 有 在 能 够 验证 响应 时 间 的 情况 下 , 才能 根据 响应 时 间 制 定 服务 级 别 协议 。 这 需要 定义 清晰 的 、 
可 测量 的 性 能 数据 以 及 与 之 相关 的 目标 。 这 些 性 能 数据 通常 被 称 作 关键 性 能 指标 ( Key Performance 
Indicator，KPI )。 有 最 理想 的 情况 是 使 用 一 种 监控 工具 收集 、 存 储 和 评估 这 些 指标 数据 。 事 实 上 ， 这 
样 做 的 目的 不 仅 是 为 了 在 某 个 目标 没有 达到 时 进行 标识 , 还 能 为 日 后 出 具 报 告 和 制定 容量 规划 而 记 
录 下 依据 。 为 了 收集 这 些 性 能 数据 ， 可 以 采用 两 种 主要 的 技术 手段 。 第 一 种 是 利用 监测 代码 
(instrumentation code ) 的 输出 结果 ( 详 见 第 2 章 ); 第 二 种 是 使 用 响应 时 间 监 控 工 具 (参见 1.3.2 节 )。 


1.1.2 ”分 析 与 设计 


架构 设计 师 根据 需求 设计 解决 方案 。 开始 的 时 候 , 为 了 定义 架构 , 需要 考虑 所 有 的 需求 。 事实 上 ， 
对 于 一 个 需要 承受 高 负载 的 应 用 程序 ， 在 设计 之 初 就 应 考虑 负载 需求 。 当 设计 时 用 到 诸如 并 行 化 、 分 
布 式 计算 或 结果 重用 等 技术 时 更 应 如 此 。 例 如 ， 设计 一 个 支持 少数 用 户 每 分 钟 执行 十 几 个 事务 的 C/S 
应 用 程序 ， 与 设计 一 个 支持 成 千 上 万 用 户 每 秒 执行 数 百 个 事务 的 分 布 式 系统 完全 是 两 码 事 。 

有 时 需求 也 会 通过 在 某 一 资源 的 使 用 上 施加 限制 来 影响 架构 。 例 如 ， 如 果 一 个 应 用 程序 用 于 通过 低 
速 网 络 连接 到 服务 需 的 移动 设备 ， 那 么 其 架构 设计 必须 考虑 能 够 支持 较 大 延迟 和 较 低 吞吐 量 。 通 常 ， 架 
构 设计 师 不 仅 需 要 预见 到 一 个 方案 可 能 出 现 的 瓶颈 ,还 要 衡量 这 些 瓶 颈 是 否 会 危及 需求 的 实现 。 如 果 架 
构 设 计 师 没 有 掌握 足够 的 信息 来 进行 这 样 的 关键 预先 评估 , 就 应 该 开发 一 个 或 甚至 多 个 原型 。 在 这 方面 ， 
如 果 没 有 前 一 阶段 收集 的 性 能 数据 ,将 很 难 做 出 明智 的 决定 。 我 所 说 的 明智 的 决定 是 指 那些 能 够 实现 以 
最 小 投资 支撑 预期 负载 的 架构 /设计 的 决定 : 简单 方案 处 理 简 单 问题 ， 精 简 方 案 处 理 复杂 问题 。 


1.1.3 ”编码 和 单元 测试 


专业 开发 人 员 编写 的 代码 应 具有 下 面 这 些 特 点 。 
口 稳定 性 : 拥有 应 对 意外 情况 的 能 力 是 所 有 软件 都 应 具备 的 特性 。 为 了 达到 预期 质量 ， 必 须 定期 
进行 单元 测试 。 这 一 点 对 于 迭代 型 生命 周期 尤为 重要 。 实 际 上 ， 在 这 类 模型 中 ， 快 速 重 构 既 有 
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代码 的 能 力 是 不 可 或 缺 的 。 例 如 ,在 调用 某 个 子 程序 时 ， 如 果 传 递 的 参数 值 超过 指定 范围 ， 系 刻 

统 就 必须 能 够 做 出 相应 处 理 而 不 至 于 崩溃 。 如 有 必要 ， 应 该 同时 生成 有 意义 的 错误 信息 

口 可 维护 性 : 能 够 长 期 运行 、 结 构 良 好 、 已 文档 化 的 可 读 代 码 比 没有 文档 化 的 粳 糕 代码 维护 起 
来 要 容易 得 多 ( 维护 费用 也 更 低 )， 例 如， 有 人 将 多 个 操作 写成 单独 一 行 上 涩 的 代码 ， 这 样 的 
开发 人 员 其 实 选 错 了 展示 才华 的 方式 

口 运行 速度 : 代码 应 该 进行 优化 ， 以 期 尽 可 能 提高 运行 速度 。 在 预期 负载 很 高 的 情况 下 更 应 如 
此 。 代 码 应 该 具有 可 伸缩 性 ， 进 而 能 够 利用 额外 的 硬件 资源 应 对 用 户 或 事务 的 不 断 增加 。 例 
如 ， 应 该 避免 不 必要 的 操作 、 串 行程 序 ， 以 及 低 效 或 不 适合 的 算法 。 然 而 ， 一 定 不 要 掉 进 过 
早 优 化 的 陷阱 。 

口 精明 的 资源 利用 : 代码 应 尽 最 大 可 能 利用 可 访问 资源 。 注 意 ， 这 并 不 总 是 意味 着 使 用 最 少 的 
资源 。 比 如 ， 应 用 程序 使 用 并 行 化 操作 比 串 行 化 操作 要 消耗 更 多 的 资源 ， 但 是 有 时 候 并 行 化 
也 许 是 解决 苛刻 负载 的 唯一 途径 。 

口 安全 性 : 母 庸 置疑， 代码 要 拥有 保证 数据 机 密 性 和 完整 性 ， 以 及 对 用 户 进行 验证 和 授权 的 能 
力 。 有 时 ， 不 可 抵赖 性 也 是 需要 考虑 的 问题 。 例 如 ， 可 能 需要 用 到 数字 签名 来 防止 终端 用 户 
否认 通信 或 合同 的 有 效 性 。 

口 可 检测 性 : 检测 的 目的 有 两 方面 。 其 一 ， 更 易于 分 析出 现 的 功能 问题 和 性 能 问题 ( 即使 是 精 
心 设计 的 系统 也 无 法 避免 这 些 问题 的 出 现 ); 其 二 ， 有 策略 地 添加 代码 以 提供 应 用 程序 的 性 能 
信息 。 例如， 通常 情况 下 ， 添 加 用 以 获取 某 一 操作 所 耗 时 间 的 代码 非常 简单 。 这 是 一 个 验证 
应 用 程序 是 否 能 够 满足 必要 性 能 需求 的 简单 有 效 的 办 法 。 

不 仅 这 些 特性 彼此 之 间 确 实 存在 一 些 冲突 ， 而 且 预 算 通 常 是 有 限 的 (有 时 甚至 非常 有 限 ) 因此 ， 


我 们 通常 有 必要 在 这 些 特 性 之 间 做 个 优先 级 排序 ,在 其 中 找到 平衡 点 ， 以 便 在 有 限 的 预算 下 实现 预期 
的 需求 。 


过 早 优 化 是 一 个 有 争议 性 的 话题 , 这 (或许 ) 源 于 DonaldKnuth 的 名 言 “ 过 早 优化 是 万 恶 之 源 ” 
基于 这 向 话 的 一 个 误解 是 ,认为 程序 员 在 编码 时 应 该 完全 忽略 优化 的 事情 。 在 我 看 来 ， 这 种 想法 是 
错误 的 。 为 了 避免 断章取义 ,让 我 们 来 看 看 这 向 名 言 的 前 因 后 果 : 

“对 于 “效率 ”一 词 的 过 度 追 求 无 疑 会 导致 混用。 程序 员 们 浪费 大 量 的 时 间 思 考 或 者 担心 他 们 

程序 中 的 非 关 键 部 分 的 运行 速度 ， 这 些 追求 效率 的 做 法 其 实 会 对 调试 和 维护 造成 极 大 的 负面 影 

响 。 我 们 应 该 忽略 微小 的 效率 因素 ， 在 约 97% 的 时 间 中 ， 过 早 优化 是 万 恶 之 源 。 但 是 我 们 不 应 

该 错过 那 关键 的 3%。 一 个 优秀 的 程序 员 不 会 因为 这 样 的 理由 而 自我 满足 。 他 知道 要 仔细 检查 

核心 代码 ， 但 前 提 是 那些 核心 代码 是 经 过 认可 的 。 预 先 判断 程序 的 核心 部 分 往往 是 一 个 错误 ， 

因为 很 多 程序 员 的 一 个 共同 经 历 是 : 在 使 用 测量 工具 后 ， 他 们 发 现 靠 直觉 的 猜测 是 错误 的 

我 对 Knuth 的 文章 的 理解 是 : 程序 员 在 编码 时 ， 不 应 该 去 关注 那些 只 能 产生 局 部 影响 的 细微 优 
化 。 相 反 ， 他 们 应 该 关心 影响 全 局 的 优化 手段 ， 比 如 系统 设计 、 实 现 所 需 功 能 所 使 用 的 算法 ， 或 者 
在 哪个 层面 (SQL、PL/SQL 、 程 序 语言 ) 的 哪些 指标 需要 进行 特殊 处 理 。 局 部 优化 应 该 等 到 测量 工 
具 显 示 某 一 模块 的 执行 时 间 过 长 之 后 再 进行 。 因 为 优化 是 局 部 的 ， 所 以 并 不 影响 系统 的 总 体 设计 
IE SC 
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1.1.4 集成 和 验收 测试 


集成 和 验收 测试 的 目的 是 验证 应 用 程序 的 功能 需求 、 性 能 需求 以 及 系统 稳定 性 。 性 能 测试 和 功能 
测试 同等 重要 ， 这 一 点 无 论 如 何 强调 都 不 过 分 。 从 各 方面 来 看 ,一 个 性 能 差 的 应 用 程序 和 没有 实现 功 
能 需求 的 应 用 程序 一 样 糟糕 。 在 这 两 种 情况 下 ， 应 用 程序 都 是 无 用 的 。 然 而 ， 只 有 明确 定义 过 性 能 需 
求 才 有 可 能 去 验证 它 。 
缺少 正式 的 性 能 需求 会 导致 两 个 主要 问题 。 第 一 , 极 有 可 能 在 集成 和 验收 测试 阶段 没有 执行 严格 
的 、 有 条 不 亲 的 压力 测试 ， 这 样 ， ee i 
第 二 ， 就 性 能 而 言 ， 无 法 明确 什么 样 的 表现 可 以 接受 ,什么 样 的 表现 不 能 接受 。 通 常 ， 只 有 在 极端 情 
a WO 
恼人 、 徒 劳 的 会 议 以 及 人 际 冲 突 就 会 随 之 出 现 。 
在 实践 中 ， 设 计 、 实 现 和 执行 良好 的 集成 和 验收 测试 来 验证 应 用 程序 的 性 能 表现 并 非 易 事 。 要 想 
取得 成 功 必须 面 对 下 面 三 个 主要 挑战 。 
口 设计 压力 测试 时 应 该 考虑 能 够 产生 典型 的 负载 。 对 此 主要 有 两 种 方法 : 一 是 让 真实 的 用 户 做 
真实 的 工作 ; 二 是 用 工具 来 模拟 用 户 。 两 种 方法 各 有 优 缺 点 ， 应 该 根据 具体 情况 进行 具体 分 
析 。 某 些 情况 下 ， 两 种 方法 可 同时 用 于 对 不 同 模块 进行 压力 测试 ， 或 者 用 两 种 方法 进行 互补 。 

口 要 产生 典型 的 负载 ， 就 需要 典型 的 测试 数据 。 不 仅 数 据 行 的 数量 和 大 小 要 符合 预期 的 量 ， 数 
据 分 布 情 况 和 数据 内 容 也 应 与 真实 数据 一 致 。 例 如 ， 如 果 属 性 中 含有 城市 名 称 ， 那 么 用 真实 
的 城市 名 称 就 比 用 像 Aaaacccc 或 Abcdefghij 这 样 的 字符 串 要 好 得 多 。 这 样 做 很 重要 ， 因 为 很 多 
情况 下 应 用 程序 和 数据 库 都 会 因为 不 同 的 数据 导致 不 同 的 表现 〈( 例 如， 索引 或 作用 于 数据 的 
函数 )。 

口 测试 的 基础 设施 要 尽 可 能 与 生产 环境 的 基础 设施 保持 一 致 。 这 对 于 高 度 分 布 的 系统 和 需要 与 

许多 其 他 系统 协作 的 系统 来 说 尤其 困难 。 

在 顺序 型 生命 周期 模型 中 , 项目 开发 接近 尾声 时 才 进 入 集成 和 验收 测试 阶段 。 如 果 导 致 性 能 问题 
的 重大 系统 架构 缺陷 此 时 才 被 发 现 ， 问 题 会 比较 环 手 。 为 避免 这 样 的 问题 ， 在 编码 和 单元 测试 阶段 也 
应 该 进行 压力 测试 。 注 意 ， 和 迭代 型 生命 周期 模型 不 存在 这 种 问题 。 事 实 上， 根据 “迭代 型 生命 周期 模 
型 ”的 定义 ， 每 一 次 迭代 都 应 该 执行 压力 测试 。 


1.2 为 性 能 而 设计 


考虑 到 应 用 程序 应 该 围绕 性 能 而 设计 ,详细 介绍 一 种 设计 方法 会 非常 有 用 。 但 是 本 书 的 焦点 是 问 
题 诊断 。 为 此 ， 这 里 只 粗略 介绍 容易 导致 性 能 欠 佳 的 十 个 最 常见 的 与 数据 库 相 关 的 设计 问题 。 


1.2.1 缺乏 数据 库 逻 辑 设计 


曾经 ， 大 家 认为 每 个 开发 项 目 理所当然 都 需要 数据 架构 师 的 参与 。 通 常 这 个 人 不 仅 负责 数据 和 数 
据 库 设计 ， 也 是 负责 应 用 程序 整体 架构 和 设计 的 团队 的 一 员 。 这 个 人 通常 拥有 极为 丰富 的 数据 库 相 关 
经 验 。 他 十 分 清楚 如 何 进 行 数据 库 设 计 以 保证 数据 的 完整 性 和 性 能 。 

遗憾 的 是 ， 现 在 大 家 并 不 总 是 这 样 认为 。 我 常常 发 现 很 多 项 目 根本 没有 经 过 正规 的 数据 库 设 计 。 


1.2 为 性 能 而 设计 加 


客户 端 或 中 间 层 设计 由 应 用 程序 开发 人 员 完 成 ， 他 们 有 时 两 者 兼顾 。 然 后 ， 突 然 间 数 据 库 设计 就 由 像 
持久 层 框 架 这 样 的 工具 生成 了 。 在 这 样 的 项 目 中 ， 数 据 库 被 视 为 存储 数据 的 “ 哑 设 备 ”。 这 种 对 于 数 
据 库 的 理解 是 错误 的 。 


1.2.2 ”实现 通用 表 


每 一 位 CIO 都 梦想 着 应 用 程序 可 以 轻松 应 对 新 出 现 的 或 变化 的 需求 。 灵 活性 是 这 里 的 关键 词 。 这 
些 梦 几 以 求 的 应 用 程序 有 时 可 以 通过 使 用 通用 数据 库 设 计 来 实现 。 这 种 情况 下 ， 添 加 新 数据 只 需 更 改 
配置 而 无 需 更 改 数据 库 对 象 本 身 。 
有 两 种 主要 的 数据 库 设计 可 用 于 实现 这 样 的 灵活 性 。 
口 实体 -属性 - 值 (EAV) 模型 : 就 像 命名 中 暗示 的 那样 ， 描 述 每 个 信息 时 都 至 少 使 用 三 列 : 实 
体 、 属 性 和 值 。 每 个 组 合 定义 一 个 与 某 一 实体 关联 的 具体 属性 的 值 。 
口 基于 XML 的 设计 : 每 张 表 只 包含 为 数 不 多 的 几 列 。 其 中 ， 必 会 出 现 这 样 两 列 : 一 个 标识 符 ， 
以 及 一 个 用 来 存储 几乎 其 他 所 有 值 的 XML 列 。 有 时 也 会 用 到 其 他 列 来 存储 元 数据 ( 例如 ， 谁 
在 何 时 做 了 最 后 一 次 修改 )。 
从 性 能 的 角度 看 ， 这 样 设计 的 问题 在 于 它们 ( 至 少 ) 不 是 最 优化 的 。 事实 上 ， 灵 活性 和 性 能 息 息 
相关 却 又 相互 矛盾 。 某 些 情况 下 即使 未 达到 最 优 的 性 能 可 能 也 足够 了 , 但 是 在 其 他 情况 下 则 可 能 是 灾 
难 性 的 。 因 此 ， 应 该 仅 在 确保 可 以 达到 所 需 性 能 时 才 进 行 灵 活 设计 。 


1.2.3 ”未 使 用 约束 加 强 数据 完整 性 


约束 ( 主键、 唯一 键 、 外 键 、 非 空 约 束 和 检查 约束 ) 不 仅 是 保证 数据 完整 性 的 基础 ， 而 且 也 广泛 
用 于 查询 优化 器 生成 执行 计划 的 过 程 中 。 如 果 不 使 用 约束 ,查询 优化 器 就 无 法 利用 很 多 优化 技术 。 除 
此 之 外 , 在 应 用 程序 级 别 上 检查 约束 将 导致 更 多 的 代码 编写 和 测试 工作 ， 并 为 数据 完整 性 带 来 潜在 问 
题 ， 因 为 总 是 可 以 在 数据 库 层面 人 为 修改 数据 。 而 且 ， 在 应 用 程序 级 别 上 检查 约束 通常 需要 消耗 更 多 
的 资源 ， 并 导致 更 少 的 可 扩展 的 加 锁 方案 ( 比如 锁 住 整 张 表 ， 而 不 是 让 数据 库 只 对 某 几 行进 行 加 锁 )。 
为 此 ， 我 强烈 建议 应 用 程序 开发 人 员 在 数据 库 级 别 定义 所 有 已 知 的 约束 。 


1.2.4 缺乏 数据 库 物 理 设 计 


很 多 项 目 没有 充分 利用 Oracle 数 据 库 提供 的 特性 ， 直 接 由 逻辑 设计 映射 出 物理 设计 ， 这 种 情形 并 
不 罕见 。 最 显而易见 的 例子 是 每 个 关系 都 直接 映射 到 一 张 堆 表 中 。 从 性 能 的 角度 看 ， 这 并 不 是 最 佳 方 
法 。 在 很 多 情况 下 ， 索 引 组 织 表 ( IOT )、 索 引 群 集 或 散 列 群集 可 能 会 提供 更 好 的 性 能 。 

Oracle 数 据 库 提供 的 索引 类 型 远 远 不 止 常 用 的 B 树 索引 和 位 图 索引 。 根 据 具 体 的 情况 ， 压 缩 索 引 、 
反 转 键 索 引 、 基 于 函数 的 索引 、 语 义 索 引 或 文本 索引 可 能 对 于 改进 性 能 非常 有 价值 。 

对 于 大 型 数据 库 , 分 区 选项 的 实现 至 关 重 要 。 大 多 数 的 数据 库 管 理 员 都 能 意识 到 这 个 选项 及 其 作 
用 . 这 里 的 一 个 常见 问题 是 开发 人 员 认 为 分 区 表 不 影响 数据 库 物理 设计 。 有 时 事实 如 此 , 有 时 则 不 然 。 
因此 我 强烈 建议 在 项 目 初期 就 开始 计划 如 何 使 用 分 区 。 

在 开发 新 应 用 程序 期 间 ， 另 一 个 需要 经 常 应 对 的 问题 是 定义 和 实现 一 个 合理 的 数据 归档 思路 。 推 
迟 这 项 工作 通常 是 不 允许 的 ， 因 为 它 可 能 会 影响 数据 库 物理 设计 ( 如 果 不 影响 逻辑 设计 的 话 )。 


8 第 1 章 性 能 问题 


1.2.5 未 正确 选择 数据 类 型 


近 些 年 来 ,我 目睹 了 数据 库 物 理 设 计 中 一 种 令 人 不 安 的 趋势 。 这 种 趋势 可 称 为 错误 数据 类 型 选择 
( 像 存储 日 期 时 使 用 VARCHAR2 替 代 DATE 或 者 TIMESTAMP 类 型 )。 乍 看 起 来 ， 选 择 数 据 类 型 似乎 是 非常 简单 
的 决定 。 然 而 ， 有 许多 目前 正在 运行 的 系统 由 于 选择 了 错误 的 数据 类 型 而 备 受 折磨 ， 这 种 系统 的 数量 
不 容 低估 。 
在 数据 类 型 选择 错误 方面 主要 存在 以 下 四 个 问题 。 
口 数据 验证 的 错误 或 缺乏 : 数据 库 引擎 必须 有 能 力 验 证 存储 在 数据 库 中 的 数据 。 例 如 ， 你 应 该 
避免 使 用 字符 串 类 型 存储 数字 值 。 这 样 做 会 需要 外 部 验证 ， 引 发 类 似 于 1.2.3 节 中 描述 的 问题 。 
口 丢失 信息 : 在 由 原始 (正确 的 ) 数据 类 型 向 ( 错误 的 ) 数据 库 数据 类 型 转化 期 间 ， 会 发 生 信 
息 丢 失 。 例 如 ， 大 家 想象 一 下 ， 用 DATE 数 据 类 型 替代 TIMESTAMP WITH TIME ZONE 数据 类 型 去 存 
储 某 个 事件 发 生 的 日 斯 和 时 间 时 会 出 现 什么 情况 。 小 数位 的 秒 和 时 区 信息 会 发 生 丢 失 。 
口 出 现 与 预期 不 符 的 结果 : 对 数据 的 顺序 有 严格 要 求 的 操作 和 功能 可 能 引发 意 想 不 到 的 结果 ， 
这 是 因为 每 种 数据 类 型 相关 的 具体 对 照 语义 是 不 同 的 。 典 型 案例 是 范围 分 区 表 和 ORDER BY 子 句 
相关 的 问题 。 
口 查询 优化 器 异常 : 查询 优化 器 可 能 会 因为 错误 的 数据 类 型 选择 做 出 错误 的 估计 ， 进 而 可 能 无 
法 选择 最 优 的 执行 计划 。 这 不 是 查询 优化 器 的 过 错 。 问 题 在 于 查询 优化 器 并 未 获得 全 部 所 需 
信息 ， 从 而 导致 其 无 法 正常 工作 。 
总 而 言 之 ， 你 有 充分 的 理由 对 数据 类 型 做 出 正确 选择 。 这 样 做 可 能 会 帮 你 避免 很 多 问题 。 


1.2.6 ”未 正确 使 用 绑 定 变量 


从 性 能 的 角度 看 ， 绑 定 变 量 既 有 优势 也 有 劣势 。 绑 定 变量 的 优势 是 它 人 允许 在 库 缓 存 中 共享 游标 ， 
从 而 避免 了 硬 解析 和 相关 开销 ; 其 劣势 是 在 用 于 WHERE 子 名 时 (也 仅 在 被 用 于 WHERE 子 句 时 )， 有 时 会 导 
致 查询 优化 器 无 法 获取 关键 信息 。 对 于 查询 优化 器 来 说 ， 要 为 每 个 SQL 语句 都 生成 最 优 的 执行 计划 ， 
使 用 字面 值 蔡 代 绑 定 变 量 会 好 很 多 。 第 2 章 会 详细 讨论 这 个 话题 。 

从 安全 的 角度 来 看 ， 绑 定 变量 预防 了 与 SQL 注入 攻击 相关 的 风险 。 实 际 上 ， 不 可 能 通过 给 绑 定 变 
量 传递 一 个 值 来 更 改 SQL 语 句 的 语法 。 


1.2.7 未 利用 数据 库 高 级 特性 


Oracle 数 据 库 是 一 款 提供 诸多 高 级 特性 的 高 端 数据 库 引 擎 ， 可 以 极 大 地 降低 开发 成 本 ， 更 不 用 说 
在 提高 性 能 时 节省 的 调试 和 bug 修 复 的 成 本 。 应 尽 可 能 利用 这 些 特 性 来 提高 投资 回报 率 。 尤 其 是 要 避 
免 重 新 开发 已 经 可 用 的 特性 ( 例如 ， 不 要 创建 自己 的 队列 系统 ， 因 为 数据 库 可 以 直接 为 你 提供 )。 即 
便 如 此 ， 第 一 次 使 用 某 个 特性 时 也 要 特别 当心 ,尤其 在 使 用 数据 库 版 本 的 新 增 特 性 时 更 应 如 此 。 不仅 
应 该 仔细 测试 该 特性 是 否 满足 需求 ， 还 要 核实 它 的 稳定 性 。 

针对 数据 库 高 级 特性 最 常见 的 争论 是 ， 当 应 用 程序 使 用 它们 以 后 便 与 所 用 的 数据 库 品牌 联 成 一 
体 ， 未 来 无 法 轻松 转换 成 其 他 数据 库 。 这 是 事实 。 但 是 ,不 管 怎样 ， 大 多 数 公司 极 少 会 去 更 换 某 个 应 
用 程序 的 数据 库 引 擎 。 相 比 只 更 换 数据 库 引 擎 ， 他 们 更 愿意 更 换 整 套 应 用 程序 。 
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我 建议 仅 在 有 充分 理由 的 情况 下 才 去 做 独立 于 数据 库 的 应 用 程序 设计 。 如 果真 有 某 种 原因 必须 做 
独立 于 数据 库 的 设计 ， 回 过 头 去 重新 阅读 1.2.2 节 中 关于 权衡 灵 活性 与 性 能 的 讨论 。 那 个 讨论 也 适用 于 
当前 的 情况 。 


1.2.8 未 使 用 PL/SQL 进行 以 数据 为 中 心 的 处 理 


上 一 节 讲 到 数据 库 高 级 特性 的 使 用 。 有 一 种 特别 情况 ， 就 是 使 用 PL/SQL 实 现 大 量 数据 的 批 处 理 。 
最 常见 的 案例 是 抽取 -转换 -加 载 ( ETL ) 过 程 。 在 这 个 过 程 中 ， 当 抽取 和 加 载 的 对 象 是 同一 数据 库 时 ， 
从 性 能 的 角度 来 看 , 转换 阶段 不 去 使 用 管理 来 源 和 目标 数据 的 数据 库 引 擎 所 提供 的 SQL 和 PL/SQL 简 直 
轧 春 至 极 。 遗 憾 的 是 ， 几 个 主流 ETL 工 具 的 体系 结构 正好 会 导致 这 样 的 轧 压 行为 。 也 就 是 说 ， 将 数据 
从 数据 库 中 抽取 出 来 ( 而 且 经 常 被 移 至 另 一 个 服务 器 )， 进 入 转换 阶段 ， 然 后 将 结果 数据 加 载 回 原来 
的 同一 个 数据 库 。 基 于 这 个 原因 ， 像 Oracle 这 样 的 供应 商 开 始 提供 在 数据 库 内 部 执行 转换 的 工具 。 为 
了 与 ETL 工 具有 所 区 分 ， 这 种 工具 通常 称 为 ELT。 为 了 达到 最 佳 性 能 ， 建 议 尽 可 能 以 数据 为 中 心 进行 
数据 处 理 。 


1.2.9 执行 不 必要 的 提交 


提交 是 串 行 化 的 操作 ( 原因 很 简单 : 只 有 二 个 LGWR 进 程 负责 将 数据 写 人 到 重 做 日 志文 件 )。 不 
言 而 喻 ， 每 个 串 行 化 操作 都 影响 可 伸缩 性 。 因 此 ， 串 行 化 是 不 受 欢 迎 的 ， 应 该 尽 可 能 最 小 化 。 一 个 办 
法 是 将 几 个 无 关 事务 放 在 一 起 执行 。 典 型 案例 是 批量 作业 加 载 很 多 行 数据 。 与 每 次 插入 后 提交 相 比 ， 
批量 提交 插入 的 数据 要 好 得 多 。 


1.2.10 ”持续 打开 和 关闭 数据 库 连接 


打开 一 个 数据 库 连 接 会 在 数据 库 服务 器 端 相应 地 打开 一 个 专 有 进程 ， 这 不 是 一 个 轻 量 级 操作 。 不 
要 低估 这 种 做 法 所 需 的 时 间 和 资源 。 最 坏 的 情形 是 ，Web 应 用 会 为 每 个 涉及 数据 库 访 问 的 请 求 都 打开 
和 关闭 一 个 数据 库 连 接 。 这 样 的 方法 是 极其 不 适宜 的 。 这 种 情形 下 使 用 连接 池 是 重 中 之 重 。 通 过 使 用 
连接 池 ， 可 以 避免 不 断 地 启动 和 停止 专 有 服务 进程 ， 从 而 避免 涉及 的 所 有 开销 。 
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早晚 都 得 讨论 应 用 的 性 能 ， 这 可 能 是 一 个 很 好 的 机 会 。 如 果 你 像 前 面 章 节 提 到 的 那样 ,仔细 定义 
过 性 能 需求 , 那么 很 容易 就 可 以 确定 应 用 程序 是 否 正 在 遭遇 性 能 问题 。 如 果 没 有 仔细 定义 过 性 能 需求 ， 
那么 答案 很 大 程度 上 会 取决 于 回答 这 个 问题 的 人 的 主观 判断 。 

有 趣 的 是 ， 实 际 上 导致 应 用 程序 性 能 被 质疑 的 大 部 分 情形 都 可 以 归纳 为 下 面 的 少数 几 类 。 

口 用 户 不 满意 应 用 程序 当前 的 性 能 表现 。 

口 系统 监控 工具 警告 某 个 基础 组 件 正 遭 遇 超 时 或 不 寻常 的 负载 。 

口 响应 时 间 监 控 工 具 通 知 你 某 个 服务 级 别 协议 没有 得 到 满足 。 

第 二 点 和 第 三 点 的 区 别 尤 为 重要 。 基 于 此 ， 接 下 来 的 两 节 将 简要 描述 这 些 监 控 方 案 。 之 后 青 来 看 
一 下 某 些 看 似 有 必要 、 实 则 没 必要 进行 优化 的 情况 。 


1 
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1.3.1 系统 监控 


系统 监控 工具 基于 一 般 系统 统计 信息 进行 健康 检查 。 其 目的 是 识别 出 不 寻常 的 负载 模式 以 及 故 
障 。 虽然 这 些 芽 具 可 以 同时 监控 整个 基础 设施 ,但 这 里 需要 强调 的 是 ,它们 只 监控 单独 的 组 件 ( 例如 
主机 、 应 用 服务 器 、 数 据 库 或 存储 子 系统 )， 而 不 考虑 组 件 间 的 作用 关系 。 因 此 ， 对 于 拥有 复杂 基础 
设施 的 环境 ， 在 支撑 基础 结构 的 单个 组 件 出 现 异常 时 ,很 难 或 者 几乎 不 可 能 评估 异常 对 系统 响应 时 间 
的 影响 。 其 中 一 个 例子 就 是 高 频 度 地 使 用 某 一 资源 。 换 句 话 说 ， 系 统 监控 工具 发 出 警报 只 是 说 明 应 用 
程序 或 者 基础 设施 中 的 某 些 组 件 可 能 出 现 了 问题 ， 而 用 户 根本 没有 察觉 到 任何 性 能 问题 ( 称 作 误 报 ); 
反之 ， 也 可 能 出 现 用 户 正 在 遭遇 性 能 问题 ， 而 系统 监控 工具 并 没有 发 现 问题 ( 称 作 漏 报 )。 最 常见 、 
也 是 最 简单 的 关于 误 报 和 漏 报 的 例子 ， 是 监控 一 个 拥有 许多 CPU 的 对 称 多 处 理 系 统 的 CPU 负载 情况 。 
假设 你 有 一 个 装 有 四 颗 四 核 CPU 的 系统 。 当 看 到 使 用 率 在 7$% 左 右 时 ， 你 可 能 觉得 这 太 高 了 ， 系 统 受 
到 了 CPU 的 限制 。 但 是 ， 如 果 执 行 任务 的 数量 远大 于 处 理 核 心 数量 ， 那 么 这 样 的 负载 就 是 很 正常 的 。 
这 便 是 一 个 误 报 。 反 之 ， 当 你 看 到 CPU 使 用 率 大 约 为 8% 时 ， 你 可 能 觉得 一 切 正常 。 但 是 如 果 系 统 正在 
执行 一 个 没有 并 行 的 单 任 务 , 那 对 于 这 个 任务 来 说 可 能 瓶颈 就 是 CPU。 实 际 上 , 100% 的 1/16 只 有 6.25% ， 
因此 单个 任务 的 CPU 使 用 率 不 能 超过 6.25%。 这 便 是 一 个 漏 报 。 


1.3.2 ”响应 时 间 监 控 


响应 时 间 监 控 工 具 ( 也 称 为 应 用 程序 监控 工具 ) 基于 由 机 器 人 产生 的 假想 事务 或 者 由 终端 用 户 产 
生 的 真实 事务 进行 监控 。 这 些 工具 测量 应 用 程序 处 理 关 键 事务 的 时 间 ， 如 果 时 间 超 出 预期 赣 值 ， 它 们 
就 会 发 出 警告 。 换 句 话说， 它们 和 用 户 一 样 利 用 基础 设施 ， 也 会 像 用 户 那样 “抱怨 ”糟糕 的 性 能 。 因 
为 它们 从 用 户 的 角度 监控 应 用 程序 ， 所 以 这 些 工具 不 仅 能 检查 单个 组 件 ， 更 重要 的 是 ， 它 们 还 能 检查 
整个 应 用 程序 的 基础 设施 。 因 此 它们 专门 用 于 监控 服务 级 别 协议 。 


1.3.3 ”强迫 性 调 优 障 碍 


曾经 有 一 段 时 间 ， 大 部 分 数据 库 管 理 员 都 患 上 一 种 叫 作 “强迫 性 调 优 障碍 ” ”的 病症 。 其 症状 是 
过 多 地 检查 性 能 相关 的 统计 信息 ( 大 部 分 都 是 基于 比率 的 )， 从 而 无 法 集中 精力 关注 真正 重要 的 事情 。 
他 们 简单 地 以 为 应 用 某 些 “简单 ”规则 ， 就 能 优化 所 管理 的 数据 库 。 历 史 告诉 我 们 ， 结 果 并 不 总 是 尽 
如 人意 。 为 什么 会 出 现 这 样 的 情况 ? 所 有 用 来 检查 某 个 给 定 比率 ( 或 值 ) 的 规则 都 是 独立 于 用 户 体验 
而 制定 的 。 也 就 是 说 ， 误 报 和 漏 报 都 是 规则 而 非 意外 。 更 糟糕 的 是 ， 大 量 的 时 间 消 耗 在 这 些 任务 上 。 

举例 来 说 ， 时 不 时 会 有 数据 库 管理 员 向 我 提出 这 样 的 问题 :“ 我 注意 到 我 们 的 一 个 数据 库 在 某 个 
门 (latch ) 上 有 大 量 的 等 待 。 怎 么 做 才能 减少 或 者 最 好 能 消除 这 些 等 待 ” ”一 般 我 会 回答 :“ 你 的 用 
户 因 为 这 个 门 锁 抱 怨 过 么 ? 肯定 没有 , 所 以 不 用 担心 。 反 倒 应 该 问 问 他 们 认为 应 用 程序 的 问题 有 哪些 。 
然后 分 析 这 些 问题 ， 你 就 会 知道 这 个 门 锁 上 的 等 待 到 底 有 没有 影响 到 用 户 。” 在 下 一 节 我 会 详细 说 明 
这 个 问题 。 


OD 这 个 绝妙 的 名 词 是 由 Gaya Krishna Vaidyanatha 发 明 的 .你 可 以 在 Oracle Insights: Tales of the Oak Table( Apress,2004 ) 
一 书 中 找到 它 的 相关 讨论 。 
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虽然 我 从 未 做 过 数据 库 管 理 员 ， 但 是 我 必须 承认 我 也 患 过 “强迫 性 调 优 障碍 "。 现 在 我 和 其 他 大 
多 数 人 一 样 ， 克 服 了 这 个 病症 。 只 不 过 与 其 他 亚 疾 一 样 ， 彻 底 治愈 “强迫 性 调 优 障碍 ”需要 花 很 长 时 
间 。 有 些 人 根本 没有 意识 到 患 了 这 种 病症 ; 有 些 人 意识 到 了 , 但 是 因为 多 年 的 沉溺 ， 总 是 很 难 去 认识 
这 样 一 个 大 错误 并 改 掉 陋 习 。 


1.4 如 何 处 理性 能 问题 


简 言 之 ， 应 用 程序 的 目标 是 向 使 用 它 的 业务 提供 便利 。 因 此 优化 应 用 程序 性 能 的 原因 就 是 最 大 
化 这 种 便利 。 这 并 不 意味 着 最 大 化 性 能 ， 而 是 要 在 成 本 和 性 能 之 间 找 到 最 佳 平 衡 点 。 事 实 上 ， 优 化 
任务 中 所 投入 的 努力 应 该 总 能 在 预期 回报 中 得 到 补偿 。 这 意味 着 从 业务 视角 来 看 ， 性 能 优化 并 非 总 
有 意义 。 


1.4.1 业务 视角 和 系统 视角 


我 们 要 优化 一 个 为 业务 提供 便利 的 应 用 程序 的 性 能 ,所 以 当 处 理性 能 问题 时 ,在 深入 应 用 程序 的 
细节 之 前 , 必须 要 理解 业务 问题 和 需求 。 图 1-2 列 出 了 拥有 业务 视角 的 人 ( 即 用 户 ) 和 拥有 系统 视角 的 
人 ( 即 工程 师 ) 之 间 的 典型 区 别 。 


证 


0 
0 
0 


不 同 的 观察 者 可 能 会 有 完全 不 同 的 视角 : 


GD 出 自 Grady Booch 的 著作 Object-Oriented Analysis and Design with dpplications 第 42 页 。 引 用 已 获得 Grady Booch 的 许 
可 。 版 权 所 有 
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理解 两 个 视角 之 间 的 因果 关系 非常 重要 。 虽 然 要 通过 业务 视角 来 理解 结果 ， 原 因 却 需要 从 系统 的 
视角 来 查看 。 所 以 ， 如 果 不 想 诊断 不 存在 的 或 者 不 相关 的 问题 ( “强迫 性 调 优 障碍 ”)， 那 么 从 业务 视 
角 来 理解 问题 所 在 就 非常 重要 ， 尽 管 这 需要 更 精细 的 工作 。 


1.4.2 ”问题 的 编 录 


处 理性 能 问题 的 第 一 步 是 从 业务 视角 识别 它们 ,并 为 其 中 的 每 一 个 问题 都 设 定 优先 级 和 目标 ， 如 
图 1-3 所 示 。 


从 业务 视角 定位 问题 为 每 个 问题 设 定 优先 级 为 每 个 问题 设 定 目标 


图 1-3” 编 录 性 能 问题 时 要 完成 的 任务 


业务 问题 无 法 通过 系统 视角 发 现 。 这 些 问 题 必 须 从 业务 视角 识别 。 如 果 对 服务 级 别 协议 的 监控 工 
作 正 常 ， 则 很 容易 通过 查看 不 满足 预期 的 操作 来 识别 性 能 问题 。 否 则 ,除了 与 用 户 或 应 用 程序 负责 人 
交谈 以 外 别 无 他 法 。 这 样 的 讨论 会 引出 一 系列 的 操作 ， 比 如 注册 新 用 户 、 运 行 报表 或 加 载 被 认为 缓慢 
的 一 堆 数 据 。 


警告 ”并非 总 是 有 必要 从 业务 视角 识别 问题 ， 有 时 候 问 题 是 已 知 的 。 例 如 ， 当 有 人 告诉 你 下 面 这 样 
的 事情 时 ， 问 题 是 需要 识别 的 :“ 终 端 用 户 经 常 抱怨 性 能 问题 ， 请 找 出 是 什么 原因 导致 的 .” 
但 是 如 果 客 户 告诉 你 “运行 菜 菜 报 表 花 费 的 时 间 太 长 "， 则 无 需 额 外 的 识别 工作 对 于 后 者 ， 
你 已 经 知道 要 去 检查 应 用 程序 的 哪个 部 分 了 ; 而 对 于 前 者 ， 你 完全 没有 头绪 ， 它 可 能 牵扯 应 
用 程序 的 任何 一 个 部 分 . 


一 旦 识别 出 有 问题 的 操作 ， 就 可 以 给 它们 分 配 优先 级 了 。 这 就 需要 提出 这 样 的 问题 ;“ 如 果 只 能 
解决 五 个 问题 , 应 该 处 理 哪 些 呢 ? ”当然 , 最 好 是 能 解决 全 部 的 问题 , 但 是 有 时 候 时 间 和 预算 都 有 限 
此 外 ， 还 应 考虑 用 于 解决 不 同 问题 的 方法 相互 冲突 的 情况 。 需 要 特别 指出 的 是 ,在 考虑 优先 级 时 ， 当 
前 的 性 能 表现 可 能 是 无 关 紧 要 的 。 例如， 如 果 你 正在 处 理 一 堆 报 表 ， 并非 一 定 是 最 慢 的 那个 享有 最 高 
的 优先 级 。 可 能 最 快 的 那个 报表 同时 也 是 执行 最 频繁 的 ， 或 者 说 是 业务 (干脆 说 是 CEO ) 最 关心 的 。 
这 张 报表 可 能 因此 拥有 最 高 优先 级 而 应 当 首先 优化 。 再 说 一 次 ， 业 务 需求 驱动 你 进行 优化 。 

对 于 每 个 问题 ， 都 应 该 设置 可 量化 的 调 优 目标 ,例如 “ 当 单 击 创建 用 户 的 按钮 之 后 ， 处 理 时 间 最 
多 两 秒 "。 如 果 性 能 需求 甚至 服务 级 别 协议 是 可 用 的 ， 那 有 可 能 优化 目标 是 已 知 的 。 否 则 ， 再 次 强调 ， 
你 必须 考虑 业务 需求 来 制定 目标 。 注 意 , 没有 目标 意味 着 不 知道 何 时 停止 寻找 更 好 的 方案 。 换 句 话说 ， 
调 优 过 程 将 永 无 止境 。 记 住 ， 投 入 和 产 出 要 平衡 。 


1.4.3 解决 问题 


同时 诊断 多 个 问题 比 诊断 单个 问题 更 加 复杂 。 因 此 应 该 尽量 每 次 只 解决 一 个 问题 。 只 要 简单 地 根 
据 问题 列表 的 优先 级 顺序 逐一 检查 就 可 以 。 
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对 于 每 个 问题 ， 都 应 该 解答 以 下 三 个 问题 ( 如 图 1-4 所 示 )。 


时 间 消 耗 在 了 哪里 ? 时 间 是 如 何 消耗 的 ? 如 何 减 少时 间 消 耗 ? 


图 1-4 要 诊断 一 个 性 能 问题 ， 你 应 该 解答 这 三 个 问题 


口 时 间 消 耗 到 哪里 啦 ? 首先 ， 你 必须 找 出 时 间 都 去 哪儿 啦 。 例 如 ， 一 个 有 具体 的 操作 花费 10 秒 钟 ， 
你 必须 找 出 这 10 秒 钟 内 哪个 模块 或 组 件 占 用 的 时 间 最 多 。 

口 时 间 是 如 何 消耗 的 ? 一 旦 知道 时 间 消 耗 到 哪些 地 方 ， 就 得 找 出 时 间 是 如 何 消耗 的 。 例 如 ， 你 
可 能 发 现 一 个 组 件 消耗 了 4.2 秒 在 CPU 上 ， 用 0.4 秒 的 时 间 做 磁盘 IO 操作 ， 用 5.1 秒 的 时 间 等 待 
来 自 另 一 个 组 件 的 出 队列 消息 。 

口 如 何 减少 时 间 消 耗 ? 最 后 ， 是 时 候 找 出 如 何 让 操作 提速 的 办 法 了 。 为 此 ， 将 精力 集中 在 最 消 
耗 时 间 的 部 分 十 分 关键 。 例 如 ， 如 果 磁 盘 IO 操作 只 占 整 个 处 理 时 间 的 4%,， 那么 开始 优化 这 些 
操作 是 没有 意义 的 ， 即 使 这 些 操作 运行 非常 缓慢 。 

要 想 找 出 时 间 消 耗 到 哪些 地 方 以 及 是 如 何 消耗 的 , 需要 从 收集 你 所 关心 的 操作 的 端 到 端 性 能 数据 
开始 。 这 一 点 很 关键 ， 因 为 如 今 开发 需要 使 用 如 Oracle 这 样 的 数据 库 应 用 程序 ， 多 层 架 构 已 成 为 事实 
标准 。 最 简单 的 情况 下 ， 至少 应 实现 两 层 ( 也 称 客户 端 /服务 端 ) 架构 。 大 多 数 时 候 是 三 层 架 构 : 展现 
层 、 逻 辑 层 和 数据 层 。 图 1-5 展 示 了 部 署 Web 应 用 程序 的 典型 结构 。 出 于 安全 或 负载 管理 的 目的 ， 也 常 
常会 将 组 件 分 布 在 多 台 计 算 机 上 。 


反 向 代理 


图 1-5 一 个 典型 Web 应 用 由 部 署 在 多 个 系统 上 的 多 个 组 件 构成 


在 多 层 架构 中 ,请 求 的 处 理 可 能 涉及 多 个 组 件 。 但 是 ,未 必 在 所 有 情况 下 处 理 某 一 请 求 时 都 涉及 
所 有 的 组 件 。 例 如 ， 如 果 激 活 了 Web 服 务 器 级 别 的 缓存 ， 一 个 请 求 可 能 只 在 Web 服 务 器 端 响应 ， 而 不 
需要 发 送 至 应 用 服务 器 端 。 当 然 同样 的 规则 也 适用 于 应 用 服务 器 或 者 数据 库 服务 器 。 

理想 情况 下 ， 要 完整 分 析 一 个 性 能 问题 ， 应 该 收集 处 理 过 程 中 涉及 的 所 有 组 件 的 详细 信息 。 某 些 
情形 下 ,尤其 是 涉及 许多 组 件 时 ， 也 许 有 必要 收集 大 量 数据 ， 这 可 能 需要 大 量 的 时 间 来 分 析 它 们 。 基 
于 这 个 原因 ， 通 常 只 有 分 步 解决 方案 才 是 处 理 问 题 的 唯一 有 效 " 途径。 分 步 解决 方案 的 思路 是 将 端 到 
端 响应 时 间 拆 分 到 它 的 主要 组 件 中 去 ， 以 此 作为 分 析 的 开始 ， 然 后 在 必要 时 才 开 始 收集 详细 信息 。 也 
就 是 说 ， 为 了 定位 性 能 问题 ， 应 该 只 收集 必要 的 、 最 少量 的 数据 。 


DD 处 理性 能 问题 时 , 不 仅 应 该 优化 正在 分 析 的 问题 ， 同 时 应 优化 操作 。 也 就 是 说 , 应 该 尽 可 能 快 地 定位 和 修复 问题 。 
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用 户 提交 请 求 用 户 响 应 时 间 


La 
| 


反 向 代理 | | | 


i 接收 响应 
| 
Web 服 务 器 | | 


| 

| 

应 和 和 re | | E 国 
数据 库 服务 器 | | 国 || 目 辆 El 
a ll me | 


图 1-6 将 一 个 请 求 的 响应 时 间 拆 分 到 所 有 主要 组 件 中 。 组 件 间 的 通信 延迟 已 忽略 


一 旦 知道 了 涉及 哪些 组 件 以 及 每 个 组 件 各 自 消耗 的 时 间 , 就 可 以 进一步 有 选择 性 地 收集 那些 最 耗 
时 间 的 组 件 的 附加 信息 ， 从 而 分 析 问 题 所 在 。 例 如 ,根据 图 1-6 所 示 , 你 只 需 考虑 应 用 服务 器 和 数据 库 
服务 器。 完整 分 析 那 些 只 占 响应 时 间 一 小 部 分 的 组 件 是 毫 无 意义 的 。 

根据 用 来 收集 性 能 数据 的 工具 或 技术 的 不 同 , 很 多 情况 下 可 能 无 法 完全 将 响应 时 间 拆 分 至 如 图 1-6 
所 示 的 每 个 组 件 中 。 况且 , 通常 也 没 必 要 这 样 做 。 实 际 上 ， 即 使 是 像 图 1-7 所 示 的 局 部 分 析 ， 也 能 帮助 
确定 是 哪些 组 件 消耗 了 大 部 分 的 啊 应 时 间 。 


用 户 响 应 时 间 


用 户 提交 请 求 、 “La 一 区 | /用 户 接收 响应 
客户 端 + 反 向 代 
a \ 加 六 
应 用 服务 器 | 
数据 库 服务 器 + 存储 攻 | 


图 1-7 ”一 个 请 求 的 响应 时 间 按 组 件 进行 部 分 分 解 


要 收集 与 问题 相关 的 性 能 数据 ， 基 本 上 只 有 以 下 两 种 可 用 方法 。 

口 检测 : 如 果 一 个 应 用 程序 的 开发 过 程 比较 合理 ， 那 么 它 一 定 包 含 检测 代码 ( instrumentation 
code )， 可 以 提供 性 能 指标 等 信息 。 通 常情 况 下 ， 检 测 代 码 处 于 禁用 状态 ， 或 者 其 输出 维持 最 
小 化 以 节省 资源 。 但 是 在 应 用 程序 运行 时 , 应 该 可 以 激活 检测 代码 或 提供 更 多 的 信息 量 。Oracle 
的 SQL 跟踪 ( 参见 第 3 章 ) 就 是 一 个 很 好 的 例子 。 它 默认 是 禁用 的 ， 但 激活 之 后 ， 却 可 以 提供 
包含 SQL 语 句 执行 的 更 多 细节 的 跟踪 文件 。 

口 探查 分 析 : 探查 器 是 一 种 性 能 分 析 工 具 ， 为 运行 中 的 应 用 程序 记录 执行 的 操作 和 执行 它们 所 
花费 的 时 间 , 以 及 系统 资源 的 使 用 情况 ( 例如 CPU 和 内 存 ), 一 些 探查 器 在 调用 层面 收集 数据 ， 
而 其 他 探查 器 则 在 代码 层面 收集 数据 。 性 能 数据 的 收集 或 是 通过 按 指定 间隔 来 抓 取 应 用 程序 
状态 , 或 是 通过 自动 运行 的 检测 代码 或 可 执行 文件 进行 。 尽 管 前 者 的 开销 更 低 一 些 , 但 是 通 
过 后 者 收集 的 数据 更 精确 。 
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通常 来 讲 ， 调 查 性 能 问题 时 两 种 方法 都 会 用 到 。 但是， 如 果 有 好 的 检测 可 用 ， 探 查分 析 则 会 较 少 
使 用 。 表 1-2 总 结 了 这 两 种 技术 的 利弊 。 


表 1-2 ”检测 和 探查 分 析 的 利弊 


技术 优势 劣势 
检测 可 以 向 关键 业务 操作 添加 计时 信息 ， 当 可 用 时 ,可 ”必须 手工 实现 ， 仅 涵盖 单个 组 件 ， 没 有 端 到 端的 
被 动态 激活 而 不 需 部 署 新 代码 ， 上 下 文 信息 可 用 ”响应 时 间 视 图 ， 通常 输出 的 格式 取决 于 编写 检测 
(例如 关于 用 户 和 会 话 的 信息 ) 代码 的 开发 者 
探查 分 析 ”对 于 整个 应 用 程序 总 是 可 用 ;多 层 探查 器 提供 端 到 ”可 能 非常 昂贵 , 尤其 是 多 层 探查 器 ; 不 能 总 是 ( 快 
端的 响应 时 间 视 图 速 地 ) 部 署 在 生产 环境 ， 在 代码 层面 工作 的 相关 
负载 可 能 会 很 高 


不 用 说 ， 只 有 当 应 用 程序 包含 检测 代码 时 才 可 以 对 其 加 以 利用 。 然 而 ,在 某 些 情形 以 及 实际 中 的 
很 多 时 候 ， 探 查分 析 经 常 是 唯一 选择 。 

在 开始 解决 某 个 特定 问题 时 ,值得 注意 的 是 ， 有 时 多 亏 副 作用 的 影响 而 使 其 他 问题 得 以 修复 ( 例 
如 ， 减 少 CPU 的 使 用 可 能 让 其 他 CPU 敏感 的 操作 获 益 ， 使 得 它们 的 运行 趋 于 正常 )。 当 然 了 ， 不 好 的 
一 面 也 有 可 能 发 生 。 采 取 应 对 措施 可 能 引入 新 的 问题 。 因 此 仔细 考虑 修复 指定 问题 时 可 能 带 来 的 所 有 
副作用 十 分 重要 。 同 时 也 必须 谨慎 评估 引入 一 个 修复 所 含 的 固有 风险 。 无 疑 所 有 的 变更 都 应 该 在 应 用 
到 生产 环境 之 前 进行 仔细 测试 。 - 

需要 注意 的 是 ,在 生产 环境 中 间 题 的 解决 顺序 并 不 总 是 依照 优先 级 。 有 些 措施 可 能 需要 花费 更 长 
的 时 间 来 实现 。 举 例 来 说 ， 变 更 一 个 高 优先 级 的 问题 也 许 需要 停机 时 间或 者 应 用 级 别 的 修改 。 结 果 就 
是 尽管 有 一 些 措施 可 以 立即 实现 ， 而 其 他 措施 则 可 能 需要 几 个 星期 或 几 个 月 甚至 更 长 的 时 间 来 实现 。 


1.5 小结 


本 章 描述 了 面 对 性 能 问题 时 的 关键 问题 : 为 什么 在 正确 的 时 间 使 用 正确 的 方法 处 理性 能 问题 是 至 
关 重 要 的 , 为 什么 一 定 要 理解 业务 需求 和 问题 所 在 , 以 及 为 什么 有 必要 就 良好 性 能 ( good performance ) 
的 含义 达成 一 致 。 

在 描述 如 何 回答 图 1-4 中 的 三 个 问题 之 前 ,需要 介绍 在 本 书 剩 余部 分 提 到 的 几 个 关键 概念 .基于 此 ， 
第 2 章 将 描述 数据 库 引 擎 在 执行 SQL 语句 的 过 程 中 执行 的 操作 。 另 外 ， 也 会 提 及 检测 的 相关 知识 并 给 
出 几 个 常用 术语 的 定义 。 


关键 概念 


本 章 的 学 习 目 标 分 为 三 个 部 分 。 首 先 ， 为 避免 不 必要 的 困惑 ， 我 会 介绍 一 些 贯 穿 全 书 的 术语 ， 其 
中 最 重要 的 包括 选择 率 、 基 数 、 游 标 、 软 解析 、 硬 解析 、 绑 定 变 量 扫 视 以 及 自 适应 游标 共享 。 其 次 ， 
我 会 描述 SQL 语句 的 生命 周期 。 换 句 话说, 我 会 介绍 为 了 执行 SQL 语句 所 涉及 的 操作 。 在 讨论 过 程 中 ， 
会 重点 关注 解析 。 最 后 ， 我 会 描述 如 何 检测 应 用 程序 代码 和 数据 库 调用 。 


2.1 选择 率 和 基数 


选择 率 ( selectivity ) 是 一 个 介 于 0 和 1 之 间 的 值 , 用 来 表示 某 个 操作 所 返回 的 记录 数 的 比例 。 例 如 ， 
一 个 操作 从 表 中 读 取 120 行 ,在 应 用 过 滤 条 件 后 ， 返 回 其 中 的 18 行 ,那么 选择 率 就 是 0.15 ( 18/120 )。 
选择 率 也 可 以 用 百分比 来 表示 ,所 以 0.15 也 可 以 表示 成 13%。 当 选择 率 接近 于 0 时 ， 称 之 为 具有 强 选择 
性 ; 当选 择 率 接近 于 1 时 ， 称 之 为 具有 弱 选 择 性 。 


警告 ”我 以 前 经 常 使 用 低 /高 或 者 好 / 坏 这 样 的 词 表示 强 / 弱 的 意思 。 之 所 以 现在 不 再 使 用 低 /高 ， 是 因 
为 这 样 的 词 无 法 明确 表达 其 指 的 是 选择 率 的 程度 高 低 还 是 其 数值 的 高 低 。 事 实 上 ， 存 在 各 种 
各 样 自 相 矛 盾 的 定义 ,我 不 再 使 用 好 / 坏 是 因为 将 质量 的 优 劣 与 选择 率 联系 在 一 起 是 不 合理 的 


一 个 操作 返回 记录 的 行 数 称 作 基 数 ( cardinality )。 公 式 2-1 解 释 了 选择 率 与 基数 之 间 的 关系 。 
基数 = 选择 率 x 行 数 
公式 2-1 选择 率 和 基数 之 间 的 关系 


警告 ”在 关系 模型 中 ， 基 数 指 关 系 中 的 元 组 数量 。 因 为 当 关系 是 一 元 的 时 候 绝对 不 包含 重复 记录 ， 
元 组 的 数量 对 应 着 其 代表 的 不 重复 值 的 数量 。 可 能 基于 这 个 原因 ， 在 一 些 出 版 物 中 ， 基 数 指 
的 是 某 列 中 不 重复 的 值 的 数量 。 因 为 SQL 允许 表 中 包含 重复 记录 (也 就 是 说 SQL 在 这 一 点 上 并 
不 遵守 关系 模型 )， 我 从 不 用 基数 表示 某 列 中 不 重复 的 值 的 数量 。 另 外 ，Oracle 自 身 在 定义 这 
个 术语 时 也 并 非 完 全 一 致 。 有 时 ，Oracle 在 文档 中 用 它 来 指 不 重复 的 值 的 数量 ， 有 时 也 用 它 来 
指 一 个 操作 返回 的 记录 行 数 。 


来 看 几 个 selectivity.sql 脚 本 的 例子 。 在 下 面 的 查询 中 ， 访 问 表 的 操作 选择 率 是 1。 这 是 因为 没 
有 应 用 WHERE 条 件 ， 因 此 查询 返回 了 表 中 的 所 有 记录 。 基 数 就 等 于 表 中 的 记录 的 行 数 ， 即 10 000。 
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SQL> SELECT * FROM t; 


10000 rows selected. 
下 面 的 查询 中 ， 访 问 表 的 操作 基数 是 2601， 因 此 选择 率 就 是 0.2601 ( 返回 10 000 行 中 的 2601 行 )。 
SOL> SELECT * FROM t WHERE n1 BETWEEN 6000 AND 7000; 


2601 rows selected. 
下 面 的 查询 中 ,访问 表 的 操作 基数 是 0， 因 此 选择 率 也 是 0 ( 返回 10 000 行 中 的 0 行 )。 
SQL> SELECT * FROM t WHERE n1 = 19; 


no rows selected. 

在 上 面 的 三 个 例子 中 , 与 访问 表 操 作 相关 的 选择 率 是 用 查询 表 返 回 的 基数 除 以 表 中 存储 的 记录 行 
数 计算 得 来 的 。 这 种 算法 之 所 以 可 行 ， 是 因为 三 个 查询 都 不 包含 连接 或 聚合 操作 。 一 旦 查询 中 包含 
GROUP BY 条 件 或 者 SELECT 中 含有 聚合 函数 ， 则 执行 计划 中 至 少 应 包含 一 个 聚合 操作 。 下 面 的 查询 说 明 
了 这 一 点 ( 注意 sum 肾 合 函 数 )。 

SQL> SELECT sum(n2) FROM t WHERE n1 BETWEEN 6000 AND 7000; 


SUM(N2) 


1 row selected. 
在 这 类 情形 下 ， 无 法 通过 查询 的 基数 ( 本 例 中 为 1 ) 计算 访问 操作 的 选择 率 ， 而 是 应 该 通过 类 似 
下 面 的 查询 找 出 访问 操作 返回 了 多 少 行 作为 聚合 函数 的 输入 。 此 时 , 访问 表 的 访问 操作 的 基数 是 2601， 
因此 选择 率 是 0.2601 ( 2601/10 000 )。 
SQL> SELECT count(*) FROM t WHERE n1 BETWEEN 6000 AND 7000; 
COUNT(*) 


1 row selected. 


接 下 来 你 会 发 现 (尤其 是 在 第 13 章 )， 了 解 一 个 操作 的 选择 率 有 助 于 找到 最 高 效 的 访问 路 径 。 


2.2 什么 是 游标 


游标 是 指向 私有 SQL 区 ( private SQL area ) 及 其 关联 的 共享 SQL 区 ( shared SQL area ) 的 句柄 ( handle， 
一 种 允许 程序 访问 某 一 资源 的 内 存 结构 )。， 如 图 2-1 所 示 ， 尽 管 句 柄 是 客户 端 内 存 结构 ， 但 它 指 向 了 服 
务 器 进程 的 内 存 结 构 ， 转 而 指向 存储 在 SGA 中 的 内 存 结构 ， 更 确切 地 说 是 库 缓存 中 的 内 存 。 
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客户 端 内 存 服务 器 进程 内 存 SGA 库 缓存 
[ ”多 本。 让 私有 SQL 区 | ------ 


图 2-1 游标 是 指向 私有 SQL 区 及 其 关联 的 共享 SQL 区 的 句柄 


私有 SQL 区 存储 诸如 绑 定 变量 值 和 查询 执行 状态 信息 等 数据 。 从 命名 上 就 可 以 看 出 ， 私 有 SQL 区 
属于 具体 的 会 话 。 用 于 存储 私有 SQL 区 的 会 话 内 存 称 作用 户 全 局 区 (UGA )。 

共享 SQL 区 包含 两 个 独立 的 结构 ， 即 所 谓 的 父 游标 (parent cursor ) 和 子 游标 ( child cursor )。 存 
储 在 父 游 标 中 的 关键 信息 是 与 游标 关联 的 SQL 语句 文本 ， 简 单 来 说 就 是 进程 将 要 执行 的 SQL 语句 。 存 
储 在 子 游标 中 的 关键 元 素 是 执行 环境 和 执行 计划 。 这 些 元 素 指 明了 执行 过 程 如 何 进行 。 一 个 共享 SQL 
区 可 以 用 于 多 个 会 话 ， 因 此 它 存储 在 库 缓 存 中 。 


注意 ”在 实践 中 ， 游标 和 私有 /共享 SQL 区 这 两 个 术语 可 互 换 使 用 。 


2.3 ”游标 的 生命 周期 


深入 理解 游标 的 生命 周期 是 优化 应 用 程序 中 SQL 语句 的 必 备 知识 。 下 面 是 处 理 游 标 过 程 中 执行 的 

(1) 打开 游标 : 在 会 话 的 UGA 中 会 分 配 一 个 用 于 打开 游标 的 私有 SQL 区 。 同 时 还 会 分 配 一 个 引用 
私有 SQL 区 的 客户 端 句 柄 。 注 意 此 时 还 没有 任何 SQL 语句 与 该 游标 相关 联 。 

(2) 解析 游标 : 共享 SQL 区 包含 与 该 SQL 语句 解析 后 相关 的 表示 形式 及 其 执行 计划 ( 用 来 描述 SQL 
引擎 如 何 执行 SQL 语句 ), 这 些 都 是 在 SGA 中 生成 和 加 载 的 ,确切 地 说 是 在 库 缓 存 中 。 私有 SQL 区 会 进 
行 更 新 ， 以 存储 一 个 对 共享 SQL 区 的 引用 。( 下 一 节 将 讨论 关于 解析 的 更 多 内 容 。) 

(3) 定 义 输 出 变量 : 如 果 SQL 语 句 返 回 数据 , 则 必须 定义 接收 数据 的 变量 , 这 不 仅 对 查询 是 必要 的 ， 
同样 适用 于 使 用 了 RETURNING 条 件 的 删除 、 插 入 和 更 新 语句 。 

(4) 绑 定 输入 变量 : 如 果 SQL 语 句 使 用 了 绑 定 变量 , 则 必须 为 绑 定 变量 提供 值 。 在 绑 定 过 程 中 不 执 
行 检 查 。 如 果 传 人 了 非法 数据 ， 在 执行 的 时 候 会 抛 出 一 个 运行 时 错误 。 

(5) 执行 游标 : 会 在 此 阶段 执行 SQL 语句 。 但 是 请 注意 , 数据 库 引擎 在 这 个 阶段 并 不 总 是 做 些 重要 
的 事情 。 实 际 上 ， 对 于 许多 类 型 的 查询 ， 真 正 的 处 理 过 程 都 会 推迟 到 获取 阶段 再 做 。 

(6) 获取 游标 : 如 果 SQL 语 句 有 结果 ， 就 在 这 一 步 取 回 结果 。 尤其 对 查询 而 言 , 这 一 阶段 会 执行 大 
部 分 的 处 理 过 程 。 查 询 的 时 候 可 能 只 取 回 结果 集 的 一 部 分 ， 换 句 话 说， 游标 可 能 在 获取 全 部 数据 之 前 
就 关闭 了 。 

(7) 关闭 游标 : 与 句柄 和 私有 SQL 区 有 关 的 资源 被 释放 并 可 以 供 其 他 游标 使 用 。 库 缓存 中 的 共享 
SQL 区 则 没有 变化 。 它 留 在 内 存 中 希望 以 后 可 以 被 重用 。 

为 了 更 好 地 理解 这 个 过 程 , 最 好 是 按 顺 序 单独 思考 图 2-2 中 执行 的 每 一 步 。 不 过 在 实践 中 , 会 使 用 
不 同 的 优化 技巧 来 加 速 处理 过 程 。 例 如 ， 绑 定 变量 扫 视 需要 将 执行 计划 的 生成 推迟 到 绑 定 变量 的 值 变 
成 已 知 的 时 候 。 
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根据 你 所 使 用 的 编程 环境 或 技术 , 图 2-2 中 描述 的 不 同步 又 可 能 会 被 显 式 执行 或 隐 式 执行 。 为 明确 
不 同 点 ， 看 一 下 图 2-2 下 面 两 段 来 自 1ifecycle.sql 脚 本 的 PL/SQL 代 码 块 。 两 者 有 相同 的 目的 (从 emp 
表 中 读 取 一 行 )， 但 是 编码 采用 完全 不 同 的 方式 。 


打开 游标 


解析 游标 


并 


游标 是 否 


返回 数据 ? 定义 输出 变量 


地 


游标 是 本 使 用 、> 一 名 定 输入 变量 


执行 游标 


游标 是 否 


返回 数据 ? 和 


有 更 多 数据 ? 


0 


关闭 游标 


OD 


图 2-2 ”游标 的 生命 周期 
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第 一 个 PL/SQL 块 使 用 dbms_sq] 包 将 图 2-2 中 的 每 一 步 进行 显 式 编码 。 


DECLARE 
1 ename emp.ename%TYPE := “SCOTT ; 
1 empno emp.empno%TYPE; 
1 cursor INTEGER; 
1 retval INTEGER; 
BEGIN 
1 cursor := dbms sql.open cursor; 
dbms_sql.parse(l cursor, "SELECT empno FROM emp WHERE ename = :ename', 1); 
dbms sql.define column(l] cursor, 1, 1 empno); 
dbms_sql.bind variable(l] cursor, ':ename', 1] ename); 
1 retval := dbms sql.execute(l cursor); 
IF dbms sql.fetch rows(l1 cursor) > 0 
THEN 
dbms_sql.column value(l cursor, 1, 1] empno); 
dbms_output.put line(] empno); 
END IF; 
dbms sql.close cursor(l] cursor); 
END; 
第 二 个 PL/SQL 代 码 块 利用 了 隐 式 游标 ; 基本 上 这 个 PL/SQL 代 码 块 将 对 游标 的 控制 全 权 委 托 给 
PL/SQL 编 译 器 了 。 
DECLARE 
1] ename emp.ename%TYPE := 'SCOTT'; 
1 _empno emp.empno%TYPE; 
BEGIN 
SELECT empno INTO 1 empno 
FROM emp 
WHERE ename = 1 ename; 
dbms output.put line(l] empno); 
END; 


多 数 的 时 间 里 编译 器 运行 良好 。 事实 上 ,编译 器 会 在 内 部 生成 与 第 一 个 代码 块 类 似 的 编码 。 但 有 
时 需要 更 多 地 控制 处 理 过 程 中 执行 的 各 个 步骤 ， 因 此 不 能 总 是 使 用 隐 式 游标 。 举 例 来 说 ， 在 这 两 个 
PLSQIL 块 之 间 ， 有 一 个 细微 但 是 重要 的 差别 。 不 管 查 询 最 终 返 回 多 少 记录 ， 第 一 个 代码 块 不 会 产生 异 
常 。 而 当 查 询 返 回 0 行 或 者 几 行 时 ， 第 二 个 代码 块 会 产生 异常 。 


2.4 解析 的 工作 原理 


上 一 节 描 述 了 游标 的 生命 周期 ， 本 节 来 关注 一 下 解析 。 如 图 2-3 所 示 ， 解 析 执 行 的 步骤 如 下 。 

(1) 包含 VPD 谓 词 : 如 果 使 用 了 虚拟 私有 数据 库 ( VPD， 以 前 也 称 作 行 级 别 安全 控制 )， 并 且 解 析 
的 SQL 语 句 其 中 的 一 张 表 激活 了 这 个 选项 ， 那 么 由 安全 策略 生成 的 谓词 就 会 包含 在 WHERE 条 件 中 。 

(2) 检查 语法 、 语 义 和 访 问 权 限 : 这 一 步 不 仅 保证 SQL 语句 是 书写 正确 的 ， 同 时 确保 SQL 语句 引用 
的 所 有 对 象 都 存在 ， 而 且 解 析 它 的 用 户 有 相应 的 权限 来 访问 这 些 对 象 。 

(3) 在 共享 SQL 区 存储 父 游 标 : 只 要 可 共享 的 父 游标 尚 不 可 访问 , 库 缓 存 中 就 会 分 配 一 些 内 存 , 新 
产生 的 父 游标 就 存储 在 这 里 。 

(4) 生成 执行 计划 : 在 这 一 阶段 ， 查 询 优化 器 为 解析 的 SQL 语句 产生 执行 计划 (这 个 话题 会 在 第 6 
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章 详 细 讨论 )。 
(5) 在 共享 SQL 区 存储 子 游标 : 此 时 会 分 配 一 些 内 存 , 可 共享 的 子 游标 就 存储 在 其 中 并 与 它 的 父 游 


标 进行 关联 。 
包含 VPD 谓 词 
检查 语法 、 语 
义 和 访 问 权限 


可 共享 的 父 游 标 
是 否 可 以 访问 ? 


将 父 游标 存储 
在 库 缓存 中 
生成 执行 计划 


将 子 游标 存储 
在 库 缓存 中 


可 共享 的 子 游标 
是 否 可 以 访问 ? 


图 2-3 解析 阶段 执行 的 步 又 


一 旦 存储 在 库 缓 存 中 ， 父 游标 和 子 游标 就 分 别 通过 视图 v$sqlarea 和 v$sql 具 体 化 了 。 严 格 来 讲 ， 
游标 的 标识 符 是 其 在 内 存 中 的 地 址 ， 对 于 父 游 标 和 子 游标 都 是 这 样 。 但 大 多 数 情况 下， 游标 通过 两 个 
列 值 定位 : sql_id 和 child_number。sql_id 列 定位 父 游 标 ; 两 个 列 在 一 起 定位 子 游标 。 但 是 也 有 例子 
表明 这 两 列 的 值 有 时 不 足以 定位 一 个 游标 。 实 际 上 ， 在 有 些 版 本 "中 ， 拥 有 许多 子 游标 的 父 游标 被 废 
弃 了 并 由 新 的 父 游标 取代 。 因 此 ， 定 位 一 个 游标 时 还 需要 address 列 。 

当 存 在 可 共享 的 父 游 标 和 子 游标 时 ， 只 需要 执行 开始 的 两 步 操作 ， 这 种 解析 称 之 为 软 解析 ; 反之 
需要 执行 所 有 的 操作 时 ， 称 之 为 硬 解析 。 

从 性 能 的 观点 来 看 ， 应 该 尽 可 能 地 避免 硬 解析 。 这 恰恰 是 数据 库 引 擎 在 库 缓存 中 存储 共享 游标 的 
原因 。 这 样 一 来 ， 属 于 这 个 实例 的 每 个 进程 都 有 可 能 重用 它们 。 应 该 尽量 避免 硬 解析 的 原因 有 两 个 : 
首先 就 是 执行 计划 的 生成 是 一 项 非常 消耗 CPU 的 操作 ; 其 次 是 存储 在 库 缓存 中 的 父 游标 和 子 游标 需要 
共享 池 中 的 内 存 。 因 为 共享 池 为 所 有 会 话 所 共享 ， 所 以 共享 池 的 内 存 分 配 是 串 行 的 。 基 于 这 个 目的 ， 


中 每 个 父 游标 可 以 拥有 的 最 大 子 游标 数量 经 历 了 几 次 变更 : 截至 11.1.0.6 版 本 , 该 数字 是 1026 个 ; 从 11.1.0.7 到 11.2.0.1 
版 本 ， 是 32 768 个 ; 在 11.2.0.2 中 是 65 536 个 ; 截至 11.2.0.3 版 本 ， 是 100 个 。 
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一 个 用 于 保护 共享 池 的 门 ( shared pool latch ) 必须 获取 分 配给 父 游标 和 子 游标 的 内 存 。 因 为 串 行 化 的 
原因 ,引发 大 量 硬 解析 的 应 用 程序 有 可 能 正在 遭遇 共享 池 的 门 的 竞争 。 尽 管 软 解析 比重 解 析 的 影响 要 
低 得 多 ， 但 是 因为 软 解析 同样 受到 序列 化 的 限制 ， 所 以 避免 软 解析 也 同样 重要 。 实 际 上 ， 数 据 库 引擎 
必须 保证 在 搜寻 可 共享 的 游标 时 所 访问 的 内 存 结构 不 被 修改 。 真实 的 实现 取决 于 不 同 的 版 本 : 10.2.0.1 
版 本 必须 获得 一 个 属于 库 缓存 的 门 (library cache latch ), 但 是 从 10.2.0.2 起 ，Oracle 开 始 用 互 斥 (mnutex ) 
替代 库 缓存 的 门 , 而 到 了 11.1 版 本 时 则 只 有 互 斥 用 于 这 个 目的 (保护 库 缓 存 )。 总 之 ,考虑 到 软 解析 和 
人 硬 解析 对 应 用 程序 可 扩展 性 的 限制 (第 12 章 会 详细 讨论 该 主题 )， 你 应 该 尽量 避免 它们 出 现 。 


2.4.1 可 共享 游标 


解析 操作 的 结果 就 是 一 个 父 游标 和 一 个 子 游 标 存储 在 库 缓存 中 的 共享 SQL 区 中 。 显 然 ， 在 共享 的 
内 存 区 域 中 存储 它们 的 目的 就 是 允许 重用 它们 从 而 避免 硬 解析 。 所 以 有 必要 讨论 一 下 哪些 情况 下 可 以 
重用 父 游 标 或 子 游标 。 本 节 列 举 了 三 个 例子 来 说 明 共 享 父 游标 和 子 游标 是 如 何 运 作 的 。 

基于 sharable_parent_cursors.sql 脚 本 的 第 一 个 例子 展示 了 一 个 父 游标 在 哪里 不 能 进行 共享 。 与 
父 游 标 相关 的 关键 信息 是 SQL 语句 的 文本 。 因 此 ， 一 般 而 言 ， 如 果 几 个 SQL 语句 的 文本 完全 一 样 才 可 
以 共享 同一 个 父 游标 。 这 是 最 核心 的 要 求 。 但 是 当 启 用 游标 共享 ( cursor sharing ) 时 也 会 出 现 例外 的 
情况 。 实 际 上 ,， 当 启用 了 游标 共享 时 ,数据 库 引擎 会 自动 用 绑 定 变量 替换 SQL 语句 中 的 字面 值 。 因 此 ， 
数据 库 引 擎 接收 到 的 SQL 语句 的 文本 在 存储 到 父 游标 之 前 被 修改 了 ( 详 见 第 12 章 )。 第 一 个 例子 中 使 
用 了 四 个 SQL 语句 ， 其 中 有 两 个 SQL 语句 有 相同 的 文本 ， 另 外 两 个 只 是 字母 大 小 写 或 者 空格 不 一 样 。 


SQL> SELECT * FROM t WHERE n = 1234; 
SQL> select * from t where n = 1234; 
SOL> SELECT * FROM t WHERE n=1234; 


SQL> SELECT * FROM t WHERE n = 1234; 
通过 v$sqlarea 视 图 ， 可 以 确定 创建 了 三 个 不 同 的 父 游标 。 同 时 注意 每 个 游标 执行 的 次 数 。 


SQL> SELECT sql id sql text; executions 
2 FROM v$sqlarea 
3 WHERE Sql text LIKE '%1234'; 


SQL_ID SQL_TEXT EXECUTIONS 
2254m1487jg50 select * from t where n = 1234 1 
89y3jtp6ru4cb SELECT * FROM t WHERE n = 1234 2 
2n8p5s2udfdsn SELECT * FROM t WHERE n=1234 1 


第 二 个 例子 的 目的 是 ,通过 sharable_child cursors.sql 脚 本 展示 父 游标 可 以 共享 而 子 游标 不 能 共 
享 。 与 子 游标 相关 的 关键 信息 是 执行 计划 和 相关 执行 环境 。 因 而 ， 几 个 SQL 语句 能 够 共享 子 游标 的 条 
件 是 它们 拥有 同一 个 父 游标 并 且 执 行 环境 是 相互 兼容 的 。 为 说 明 这 一 点 ， 在 给 初始 化 参数 
optimizer_ mode 设 置 两 个 不 同 值 的 情况 下 执行 同一 个 SQL 语句 。 

SQL> ALTER SESSION SET optimizer mode = all Tows; 
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SQL> SELECT count(*) FROM 七 ; 


COUNT(*) 


SQL> ALTER SESSION SET optimizer mode = first rows 1; 
SQL> SELECT count(*) FROM t; 


COUNT(*) 


执行 的 结果 是 创建 了 一 个 单独 的 父 游标 ( 5tjqf7sx5dzmj ) 和 两 个 子 游标 ( 0O 和 1 )。 同 时 还 要 注意 到 
两 个 子 游标 都 拥有 相同 的 执行 计划 ( plan_hash_value 列 的 值 相同 )， 这 很 好 地 证 明了 创建 新 的 子 游标 
是 因为 新 的 截然 不 同 的 执行 环境 ， 而 不 是 因为 生成 了 另 一 个 执行 计划 。 

SQL> SELECT sql id, child number, optimizer mode，plan_hash_value 


2 FROM v$sql 
3 WHERE sql text = "SELECT count(*) FROM t'; 


SQL ID CHILD NUMBER OPTIMIZER_MODE PLAN_ HASH VALUE 
Stjqf7sx5dzmj 0 ALL_RONS 2966233522 
5tjqf7sx5dzmj 1 FIRST_ROWS 2966233522 


警告 ”如 上 面 的 例子 所 示 ，1 号 子 游标 optimizer mode 列 的 值 没 有 正确 显示 。 实 际 上 ， 该 列 显示 的 是 
FIRST_ROWS， 而 不 是 FIRST_ROWS 1。 同样 的 行为 也 可 以 在 使 用 FIRST _ROWS 10、FIRST_ROWS_100 
和 FIRST_RONS_1000 时 观察 到 。 这 可 能 会 导致 潜在 的 问题 : 即使 执行 环境 不 一 样 ，SQL 引 擎 也 
不 区 分 其 中 的 不 同 。 因 此 ， 可 能 会 错误 地 共享 子 游标 。 


要 想 知道 哪些 不 匹配 导致 出 现 了 几 个 子 游 标 , 可 以 查询 vgsql_shared cursor 视图。 在 这 个 视图 中 
你 可 能 会 发 现 , 对 于 每 个 子 游标 ( 除了 第 一 个 编号 为 0 的 ), 都 会 显示 为 何不 能 共享 之 前 建立 的 子 游标 。 
对 于 几 种 类 型 的 不 一 致 ( 在 12.1 版 本 中 是 64 个 ), 都 有 一 列 将 值 设置 为 N ( 没有 不 匹配 ) 或 Y (不 匹配 )。 
通过 下 面 的 查询 ， 可 以 确认 在 之 前 的 例子 中 ， 第 二 个 子 游标 的 不 匹配 是 由 于 不 同 的 优化 器 模式 。 


SQL> SELECT optimizer mode mismatch 
2 FROM v$sql shared cursor 
3 WHERE sql id = 'stjqf7sx5dzmj' 
4 AND child number = 1; 


OPTIMIZER MODE MISMATCH 


在 11.2.0.2 中 ，v$sql_shared_cursor 视 图 提供 一 个 称 作 reason 的 列 。 该 列 不 仅 提供 导致 出 现 新 的 子 
游标 不 匹配 的 文本 描述 ， 而 且 提 供 不 匹配 的 的 额外 信息 。 因 为 reason 列 包含 的 信息 和 不 匹配 的 类 型 息 
息 相 关 ， 所 以 它 的 类 型 是 CLOB, 并 且 它 使 用 XML 格式 。 例 如 , 在 接 下 来 的 示例 中 , 三 个 XML 元 素 包 含 


> 
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了 关键 信息 。 原 因 ( Optimizer mismatch ) 存储 在 reason 元 素 中 ， 库 缓存 中 已 存在 的 游标 的 优化 器 模式 
(也 就 是 1, 表示 ALL_ROWS ) 存储 在 optimizer_mode_cursor 元 素 中 , 会 话 解析 语句 所 需 的 优化 器 模式 ( 2， 
即 FIRST_ROWS ) 存储 在 optimizer mode current 元 素 中 。 
SQL> SELECT reason 
2 FROM v$sql shared cursor 


3 WHERE sql id = '5tjqf7sx5dzmj" 
4 AND child number = 0; 


REASON 


“ChildNode><ChildNumber>0</ChildNumber><ID>3</ID><Treason>Optimizer mismatch(10)</VTeason><Siz 
e>3x4</Ssize><optimizer mode hinted cursor>0¢/optimizer mode hinted cursor><optimizer mode cu 
rsor>1¢</optimizer mode cursor><optimizer mode current>2¢/optimizer mode current></ChildNode> 


SQL> SELECT x.reason, 


2 decode(x.optimizer mode cursor, 

3 1, 'ALL ROWS', 

4 2, 'FIRST ROWS', 

5 3 " RULE; 

6 4, 'CHOOSE', x.optimizer mode cursor) AS optimizer mode cursor, 

7 decode(x.optimizer mode current, 

8 15 “ALL RONS 

9 2, FIRST_ROWS ， 

10 3, “RULE "， 

11 4, 'CHOOSE', x.optimizer mode current) AS optimizer mode current 

12 FROM v$sql shared cursor s, 

13 XxMLTable('/ChildNode' 

14 PASSING XMLType(reason) 

15 COLUMNS 

16 reason VARCHAR2(100) PATH '/ChildNode/reason', 

还 optimizer mode cursor NUMBER PATH '/ChildNode/optimizer mode CUTSOT ， 
18 optimizer mode current NUMBER PATH '/ChildNode/optimizer mode current' 
19 东区 


20 WHERE s.sql id = '5tjqf7sx5dzmj' 
21 AND s.child number = 0; 


REASON OPTIMIZER MODE CURSOR OPTIMIZER_ MODE CURRENT 


Optimizer mismatch(10) ALL_ROWS FIRST_ROWS 

第 三 个 例子 仍然 是 基于 sharable_child_cursors.sql 脚 本 ， 目 的 是 展示 执行 环境 不 仅 影响 执行 计 
划 ， 还 有 可 能 会 影响 SQL 语句 的 结果 。 这 也 是 共享 子 游标 的 执行 环境 必须 相互 兼容 的 另 一 个 原因 。 例 
如 ， 下 面 的 SQL 语句 的 输出 证 实 了 nls_sort 初 始 化 参数 的 影响 。 

SQL> ALTER SESSION SET nls_sort = binary; 


SQL> SELECT * FROM t ORDER BY pad; 


2.4 解析 的 工作 原理 25 


3 2 
4 z 
SOL> ALTER SESSION SET nls sort = xgerman; 


SQL> SELECT * FROM t ORDER BY pad; 


因为 执行 环境 的 不 同 ， 使 用 了 同一 个 父 游标 下 的 两 个 子 游标 。 注 意 在 这 个 案例 中 ,不 匹配 可 以 通 
过 v$sql_shared_cursor 视 图 查看 ， 特 别 是 在 language_mismatch 列 中 。 


SQL> SELECT sql id，child_number，plan_hash_value，executions 
2 FROM v$sql 
3 WHERE sql text = 'SELECT * FROM 七 ORDER BY pad'; 


SQL ID CHILD NUMBER PLAN_ HASH VALUE EXECUTIONS 
1f7qg6nu4oshd 0 961378228“ 1 
1f7qg6nu40shd 1 961378228 


SOL> SELECT child number, language mismatch 
2 FROM v$sql shared cursor 
3 WHERE sql id = '1f7qg6nu40shd" 
4 AND child number > 0; 


CHILD NUMBER LANGUAGE MISMATCH 


在 实践 中 ， 由 不 可 共享 的 父 游 标 导 致 的 硬 解 析 远 比 由 不 可 共享 的 子 游标 导致 的 硬 解 析 更 加 常见 。 
事实 上 ， 多 半 情 况 是 因为 每 个 父 游 标 只 有 较 少 的 子 游标 。 如 果 父 游标 无 法 共享 ， 通常 是 因为 SQL 语 句 
的 文本 变更 的 结果 。 这 多 发 于 SQL 语句 由 应 用 程序 动态 生成 或 用 字面 值 蔡 代 了 绑 定 变量 的 情况 。 一 般 
来 讲 动态 生成 SQL 语句 无 法 避免 。 另 一 方面 ， 通 常 都 可 以 使 用 绑 定 变量 。 但 是 ， 并 不 是 什么 情况 下 都 
适合 使 用 绑 定 变量 。 接 下 来 关于 绑 定 变量 利 整 的 讨论 ， 可 以 帮 你 理解 什么 时 候 使 用 它们 是 合适 的 ， 什 
么 时 候 是 不 合适 的 


2.4.2 ” 绑 定 变量 


绑 定 变量 通过 三 种 方式 影响 应 用 程序 。 第 一 ， 从 开发 角度 来 看 ， 它 们 既 可 以 让 编程 变 简单 ， 也 可 
以 让 编程 变 复 杂 ( 更 准确 地 说 ， 就 是 需要 编写 的 代码 或 多 或 少 )。 这 种 情况 下 ， 影 响 取决 于 用 来 执行 
SQL 语句 的 应 用 编程 接口 。 例如 ,如果 你 正在 编写 PL/SQL 人 代码， 使 用 绑 定 变量 来 执行 会 更 容易 。 另 一 
方面 ,如果 你 正在 使 用 JDBC 编 写 Java 程 序 ， 没 有 绑 定 变量 的 情况 下 执行 SQL 语句 会 更 容易 。 第 二 ， 从 
安全 角度 看 ， 绑 定 变 量 减 轻 了 SQL 注入 攻击 的 风险 。 第 三 ， 从 性 能 角度 看 ， 使 用 绑 定 变量 有 利 有 弊 。 


注意 在 接 下 来 的 小 节 里 ， 你 会 看 见 一 些 执行 计划 。 第 10 章 将 阐述 如 何 获得 和 解释 执行 计划 。 如 果 
你 读 完 第 10 章 后 有 什么 不 清楚 的 ， 可 以 考虑 回 过 头 来 阅读 本 章 。 


1. 优势 

绑 定 变量 在 性 能 方面 的 优势 是 它们 允许 共享 库 缓存 中 的 父 游 标 , 这 样 就 避免 了 硬 解析 以 及 相关 的 
额外 开销 。 接 下 来 的 例子 是 对 脚本 bind variables_graduation.sql 的 输出 的 摘录 ， 展 示 了 三 个 INSERT 
语句 由 于 使 用 绑 定 变量 而 共享 了 库 缓 存 中 的 同一 个 游标 。 


SQL> 
SOL> 
SQL> 
SQL> 
SOL> 
SQL> 
SQL> 
SOL> 
SQOL> 


2 
3 


VARIABLE n NUMBER 

VARIABLE v VARCHAR2(32) 

EXECUTE Sm ss 1 Vv: v= "Helicon's 
INSERT INTO t (n, v) VALUES (:n, :v); 
EXECUTE sn Es 23 Sw Bs "Tantor’; 
INSERT INTO t (n, v) VALUES (:n, :v); 
EXECUTE :n := 3; :Vv := 'Kalgan’; 

INSERT INTO t (n, v) VALUES (:n, :v); 
SELECT sql id, child number, executions 


FROM v$sql * 
WHERE sql text = "INSERT INTO t (n, v) VALUES (:n, ;Vv)'; 


SQL_ID CHILD NUMBER EXECUTIONS 


6cvmu7dwnvxwj 0 a 


但 是 有 些 情况 下 , 即使 使 用 了 绑 定 变量 , 还 是 创建 了 几 个 子 游标 , 如 下 面 的 例子 所 示 。 注 意 , INSERT 
语句 和 之 前 的 例子 是 一 样 的 。 只 是 VARCHAR2 变 量 的 最 大 值 发 生 了 改变 ( 从 32 到 33 )。 


SOL> VARIABLE v VARCHAR2(33) 
SQL> EXECUTE :n := 4; :Vv := 'Terminus'; 
SQL> INSERT INTO t (n, v) VALUES (:n, :Vv); 
SQL> SELECT sql] id, child number, executions 
2 FROM v$sql 
3 WHERE sql text = 'INSERT INTO t (n，v) VALUES (:n, :v)'; 
SoL ID CHILD NUMBER EXECUTIONS 
6cvmu7dwnvxwj 0 3 
6cvmu7dwnvxwj 1 4 
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创建 新 的 子 游标 ( 1 ) 是 因为 前 面 三 个 INSERT 语 句 和 第 四 个 之 间 的 执行 环境 发 生 了 改变 。 下 面 的 例 
子 中 的 不 匹配 项 ， 可 以 通过 查询 v$sql_shared_cursor 视 图 来 确认 。 注 意 ，bind_length_upgradeable 列 
只 在 11.2 版 本 中 存在 。 在 之 前 的 版 本 中 ， 这 个 信息 由 bind_mismatch 列 提供 。 


SQL> SELECT child number, bind length upgradeable 
2 FROM v$sql shared cursor 
3 WHERE sql id = '6cvmu7dwnvxwj'; 


CHILD NUMBER BIND LENGTH UPGRADEABLE 


家 于 
这 是 因为 数据 库 引 擎 使 用 了 一 个 叫 作 绑 定 变 量 分 级 的 特性 。 这 个 特性 的 目标 是 通过 将 绑 定 变量 按 
等 级 ( 随 大 小 变化 ) 分 成 四 个 组 来 最 小 化 子 游标 的 数量 。 第 一 组 包含 最 大 至 32 字 节 的 绑 定 变量 ， 第 二 
个 组 包含 33 至 128 字 节 的 绑 定 变量 ， 第 三 组 包含 大 小 为 129 至 2000 字 节 的 绑 定 变量 ， 最 后 一 组 包含 大 于 
2000 字 节 的 绑 定 变量 。NUMBER 数 据 类 型 的 绑 定 变量 按 它们 的 最 大 长 度 22 字 节 划 分 等 级 。 如 下 面 的 例子 
所 示 ，v$sql_bind_metadata 视 图 显示 了 每 个 组 的 最 大 长 度 。 注 意 值 128 的 用 法 ， 即 使 子 游标 1 的 绑 定 变 
量 长 度 定义 为 33。 
SQL> SELECT s.child number, m.position, m.max length, 
2 decode(m.datatype, 1, 'VARCHAR2' ,2, 'NUMBER' ,m.datatype) AS datatype 
3 FROM v$sql s, v$sql bind metadata m 
4 WHERE s.sql id = '&sql id- 
5 AND s.child address = m.address 
6 ORDER BY 1, 2; 


CHILD NUMBER POSITION MAX LENGTH DATATYPE 


0 1 22 NUMBER 
0 2 32 VARCHAR2 
入 4 22 NUMBER 
1 2 128 VARCHAR2 


注意 ”这 个 例子 展示 了 当 使 用 不 同 组 的 绑 定 变量 时 出 现 了 绑 定 错 配 的 情况 。 只 有 当 关 联 到 新 的 组 的 
绑 定 变量 比 原 来 大 时 才 会 出 现 这 种 情况 。 实 际 上 ， 仔 细 回 顾 这 个 例子 ， 绑 定 变量 的 大 小 一 直 
在 增加 。 如 果 它 们 是 在 减 小 ,那么 所 有 的 执行 都 可 以 共享 同一 个 子 游标 。 如果 用 VARCHAR2 类 型 
的 最 大 值 创建 子 游标 ， 那 么 所 有 比 它 小 的 VARCHAR2 绑 定 变 量 都 可 以 共享 它 。 


很 显然 , 每 次 产生 一 个 新 的 子 游标 就 表示 一 个 执行 计划 的 生成 。 这 个 新 的 执行 计划 是 否 能 够 被 其 
他 子 游标 使 用 也 取决 于 绑 定 变量 的 值 。 这 部 分 内 容 将 在 下 一 节 讨 论 。 


2. 劣势 

在 WHERE 条 件 中 使 用 绑 定 变量 对 于 性 能 方面 的 劣势 是 ， 在 某 些 条 件 下 会 对 查询 优化 器 隐藏 重 要 的 
信息 。 事 实 上 ， 对 于 查询 优化 器 而 言 ， 获 取 字 面值 比 使 用 绑 定 变量 更 好 。 使 用 字面 值 时 ， 查 询 优化 器 
总 能 够 做 出 最 接近 的 估算 。 当 涉及 范围 比较 谓词 (例如 基于 BETNEEN、 大 于 或 小 于 的 比较 条 件 )， 检 查 
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内 


一 个 值 是 否 在 可 用 值 范围 之 外 时 ( 即 小 于 列 中 存储 的 最 小 值 或 大 于 列 中 存储 的 最 大 值 )， 或 者 使 用 直 
方 图 时 ， 情 况 尤其 如 此 。 例 如 ， 拿 一 个 1000 行 数据 的 表 来 说 ， 在 id 列 上 ， 所 有 的 整 型 值 都 在 1 ( 最 小 
值 ) 和 1000 ( 最 大 值 ) 之 间 。 


SOL> SELECT count(id), count(DISTINCT id), min(id), max(id) FROM 七 ; 


COUNT(ID) COUNT(DISTINCTID) MIN(ID) MAX(ID) 


当 一 个 用 户 选择 id 小 于 990 的 所 有 记录 时 ， 查 询 优 化 器 就 知道 ( 归功 于 对 象 统计 信息 ) 表 中 大 约 
99% 的 数据 被 选中 了 。 因 此 ， 它 会 选择 使 用 全 表 扫 描 的 执行 计划 。 同 时 还 要 注意 估算 的 基数 ( 执行 计 
划 中 的 Rows 列 ) 几乎 准确 对 应 查询 应 返回 的 行 数 。 

SQL> SELECT count(pad) FROM 七 WHERE id < 990; 


COUNT(PAD) 
989 
| Id | Operation | Name | Rows | 


| 0 | SELECT STATEMENT | | 
| 1| SORT AGGREGATE | | 1 
| 2| TABLE ACCESS FULL| T | 990 


当 另 一 个 用 户 选择 id 小 于 10 的 所 有 记录 时 ,查询 优化 器 知道 表 中 仅 有 大 约 1% 的 数据 被 选中 ,因此 ， 
它 选择 使 用 索引 扫描 的 执行 计划 。 在 这 个 例子 中 同样 要 注意 其 非常 准确 的 估算 ， 
SQL> SELECT count(pad) FROM 七 WHERE id < 10; 


COUNT(PAD) 
9 
| Id | Operation | Name | Rows | 


0 | SELECT STATEMENT 

1 | SORT AGGREGATE 

2 | TABLE ACCESS BY INDEX ROWID| 
下 INDEX RANGE SCAN | 


处 理 绑 定 变量 时 ,查询 优 化 器 习惯 于 忽略 它们 的 值 。 因 此 ， 像 之 前 的 例子 中 的 完美 估算 是 不 可 能 
的 。 为 解决 这 个 问题 ，Oracle9i 中 引入 了 一 个 叫 作 绑 定 变量 扫 视 (bind variable peeking ) 的 特性 。 绑 定 
变量 扫 视 的 概念 很 简单 : 在 生成 执行 计划 之 前 , 查询 优化 器 扫 视 绑 定 变量 的 值 并 将 其 作为 字面 值 使 用 . 
这 个 方法 的 问题 在 于 执行 计划 的 生成 依赖 于 第 一 次 执行 所 提供 的 值 。 下 面 这 个 基于 bind_variables_ 
peeking.sql 脚 本 的 例子 就 验证 了 这 种 行为 。 注 意 第 一 次 优化 是 按照 值 990 执 行 的。 结果 就 是 查询 优化 
右 选 择 全 表 扫 描 。 正 是 这 个 选择 ,一 旦 游标 被 共享 ， 就 会 影响 使 用 值 为 10 的 第 二 个 查询 
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SOL> VARIABLE id NUMBER 
SQL> EXECUTE :id := 990; 


SQL> SELECT count(pad) FROM t WHERE id < :id; 


COUNT (PAD) 
989 
| Id | Operation | Name | Rows | 


0 | SELECT STATEMENT 
| 1 | SORT AGOREGATE 
2 | TABLE ACCESS FULL| T | 990 


[uy 


SQL> EXEQVTE :2 := 0; 


SQL> SELECT count(pad) FROM t WHERE id < :id; 


COUNT(PAD) 

A pa 
9 

| Id | Operation | Name | Rows | 


0 | SELECT STATEMENT 
| 1 | SORT AGGREGATE 
2 | TABLE ACCESS FULL| T | 990 


当然 ， 如 下 例 所 示 ， 如 果 第 一 个 执行 换 成 值 10， 查 询 优化 器 就 会 选择 使 用 索引 扫描 的 执行 计划 ， 
这 意味 着 两 个 查询 又 一 次 都 这 样 做 了 。 注意 , 为 避免 和 前 一 个 例子 共享 游标 , 查询 用 小 写字 母 来 书写 。 
SQL》 EXECUTE :id := 10; 


2 


SQL> select count(pad) from t where id < :id; 


COUNT(PAD) 

9 
| Id | Operation | Name | Rows | 
| 0 | SELECT STATEMENT | | | 
| 1 | SORT AGGREGATE | | 1 | 
| 2| TABLE ACCESS BY INDEX ROWID| T | 9 | 
| 3| INDEX RANGE SCAN | Erk | 9 | 


SQL> EXECUTE :id := 990; 


SQL> select count(pad) from t where id“ :id; 


COUNT (PAD) 
989 
| Id | Operation | Name | Rows | 


| 0 | SELECT STATEMENT | 
| 1 | SORT AGGREGATE | 
| 2 | TABLE ACCESS BY INDEX ROWID| T 
| 3| INDEX RANGE SCAN 和 


一 定 要 理解 ， 只 要 游标 保留 在 库 缓 存 中 并 可 以 共享 ， 就 会 被 重用 。 这 和 与 其 关联 的 执行 计划 的 效 
率 无 关 。 

为 解决 这 个 问题 ， 从 11.1 版 本 开始 ， 数据库 引 擎 启用 一 个 称 为 自 适 应 游标 共享 ( adaptive cursor 
sharing， 也 称 为 绑 定 感知 游标 共享 ，bind-aware cursor sharing ) 的 新 特性 。 它 的 目的 是 自动 识别 出 因 
重复 利用 已 经 可 用 的 游标 导致 的 低 效 的 执行 。 要 理解 这 个 特性 如 何 工作 ,我 们 从 查看 由 v$sql 提 供 的 
一 些 信息 开始 。 下 面 是 11.1 版 本 中 可 用 的 新 列 。 

口 is_bind_sensitive 不 仅 表 明 绑 定 变量 扫 视 是 否 用 于 生成 执行 计划 ， 同 时 也 表示 自 适 应 游标 共 

享 可 能 会 被 考虑 。 如 果 是 这 样 ， 此 列 值 设置 为 Y， 否 则 就 设置 为 N。 
口 is_bind_aware 表 明 游标 是 否 使 用 自 适应 游标 共享 。 如 果 是 , 列 值 为 Y; 如 果 不 是 , 则 设置 为 N。 
口 is_shareable 表 明 游标 是 否 可 共享 。 如 果 可 以 列 设置 为 Y; 否则 , 值 为 N。 如 果 值 为 N， 则 游 
标 不 再 被 重用 。 

下 面 的 例子 来 自 于 adaptive cursor_ sharing.sql 脚 本 ， 游 标 是 可 共享 的 并 且 是 绑 定 变量 的 ， 但 并 

没有 使 用 自 适 应 游标 共享 。 


SOL> EXECUTE, sid ss 103 
SQL> SELECT count(pad) FROM 七 WHERE id < :id; 


COUNT(PAD) 


SQL> SELECT sql id 
2 FROM v$sqlarea 
3 WHERE sql text = “SELECT count(pad) FROM 七 WHERE id < :id'; 


asthimx10aygn 


SQL> SELECT child number, is bind sensitive, is bind aware, is shareable, plan hash value 
2 FROM v$sql 
3 WHERE sql id = “asthlmx10aygn ; 
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CHILD NUMBER IS BIND SENSITIVE IS BIND AWARE IS SHAREABLE PLAN HASH VALUE 


oY N Y 4270555908 


当 游 标 使 用 不 同 的 绑 定 变量 值 执行 了 几 次 后 ， 有 意思 的 事情 发 生 了 。 注 意 下 面 编号 为 0 的 子 游标 


不 再 是 可 共享 的 ， 并且 两 个 新 的 子 游标 替换 了 它 ， 它 们 都 使 用 了 自 适应 游标 共享 。 


SQL> EXECUTE :id := 990; 

SQL> SELECT count(pad) FROM t WHERE id < :id; 
COUNT(PAD) 

SQL> EXECUTE :id := 10; 

SQL> SELECT count(pad) FROM t WHERE id < :id; 
COUNT(PAD) 


SQL> SELECT child number, is bind sensitive, is bind aware, is shareable, plan hash value 
2 FROM v$sql 
3 WHERE sql id = 'asthimxi0aygn’ 
4 ORDER BY child number; 


CHILD NUMBER IS BIND SENSITIVE IS BIND AWARE IS SHAREABLE PLAN HASH VALUE 


OY N N 4270555908 
LY ¥ Y 2966233522 
2 ¥ Y 4270555908 


查看 与 游标 关联 的 执行 计划 ， 可 能 如 你 所 期 待 的 ， 你 会 看 见 其 中 一 个 新 的 子 游标 拥有 基于 全 表 扫 


描 的 执行 计划 ， 而 另 一 个 则 基于 索引 扫描 。 


Plan hash value: 4270555908 


0 | SELECT STATEMENT | 
1 | SORT AGGREGATE | 
2 | TABLE ACCESS BY INDEX ROWID| 
s 汉 | INDEX RANGE SCAN | 


0 | SELECT STATEMENT 
| 1 | SORT AGGREGATE 
2 | TABLE ACCESS FULL| T | 
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淳 


要 进一步 分 析 两 个 新 的 子 游 标 产生 的 原因 ， 可 以 使 用 下 面 几 个 动态 性 能 视图 : v$sql_cs_ 
statistics、v$sql cs selectivity 和 v$sql cs_histogram。 第 一 个 视图 表明 是 否 使 用 了 扫 视 以 及 与 每 
个 子 游 标 相 关 的 执行 统计 信息 。 在 下 面 的 输出 中 ， 可 以 确认 对 于 一 次 执行 ， 子 游标 1 处 理 的 行 数 比 子 
游标 2 要 高 。 这 是 查询 优化 器 在 一 种 情况 下 选择 全 表 扫 描 而 在 另 一 种 情况 下 选择 索引 扫描 的 主要 原因 。 

SQL> SELECT child number, peeked, executions, rows processed, buffer gets 

2 FROM v$sql cs statistics 


3 WHERE sql id = 'asthimx10aygn’' 
4 ORDER BY child number; 


CHILD NUMBER PEEKED EXECUTIONS ROWS PROCESSED BUFFER GETS 


人 ¥ 于 19 3 
FY 1 990 18 
2 %¥ 1 19 3 


v$sql_cs_selectivity 视 图 显示 与 每 个 子 游标 的 每 个 谓词 相关 的 选择 率 范围 。 实 际 上 ， 数 据 库 引 
擎 并 不 会 为 每 个 绑 定 变量 值 创 建 一 个 新 的 子 游标 。 相 反 ， 它 将 拥有 大 致 相同 的 选择 率 的 值 分 到 同一 个 
组 ， 从 而 导致 相同 的 执行 计划 。 
SQL> SELECT child number, trim(predicate) AS predicate, low, high 
2 FROM v$sql cs selectivity 


3 WHERE sql id = 'asthimx10aygn’' 
4 ORDER BY child number; 


CHILD NUMBER PREDICATE LOW HIGH 
1 <ID 0.890991 1.088989 
2 «ID 0.008108 0.009910 


v$sql_cs_selectivity 视 图 的 信息 不 仅 用 于 展示 每 个 子 游标 的 选择 率 范围 ， 而 且 数 据 库 引擎 也 可 
使 用 该 信息 来 选择 使 用 哪个 子 游标 。 实 际 上 ， 当 一 个 游标 是 绑 定 感知 的 ， 绑 定 变 量 扫 视 会 取代 每 一 次 
的 解析 执行 ， 而 且 游 标的 谓词 选择 率 是 基于 估算 的 。 根 据 这 个 估算 选用 正确 的 子 游标 。 或者， 如 果 没 
有 适用 于 这 个 选择 率 范围 的 游标 ， 则 创建 一 个 新 的 子 游标 。 


警告 ” 绑 定 感知 的 游标 是 必要 的 ， 对 于 每 次 解析 ， 查 询 优化 器 都 对 它们 的 谓词 进行 选择 率 的 估算 
基于 这 个 原因 ， 数 据 库 引擎 有 时 会 禁用 自 适应 游标 共享 。 有 两 个 常见 情况 需要 考虑 : 第 一 个 
是 当 SQL 语句 包含 的 绑 定 变量 超过 14 个 时 ; 第 二 个 是 当 查询 优化 器 不 能 正确 估算 选择 率 时 。 例 
如 ， 当 变量 需要 隐 式 数据 类 型 转换 ( 这 是 使 用 正确 数据 类 型 的 另 一 个 理由 )， 选 择 率 无 法 估算 
出 来 时 ， 或 者 引用 的 对 象 没有 对 象 统计 信息 时 。 


v$sql_cs_histogram 视 图 的 内 容 由 SQL 引擎 用 来 决定 何 时 将 一 个 游标 置 于 绑 定 感知 ,以 及 应 何 时 使 
用 自 适应 游标 共享 。 对 于 每 一 个 子 游标 ， 这 个 视图 会 显示 三 个 桶 。 第 一 个 桶 〈bucket id 等 于 0 ) 与 高 
效 的 执行 相关 ， 第 二 个 桶 (bucket_id 等 于 1 ) 与 低 效 的 执行 相关 ， 第 三 个 桶 (bucket_id 等 于 2 ) 与 效 
率 非常 低 的 执行 相关 。 思 路 是 : 在 完成 一 次 执行 后 ，SQL 引 擎 比较 估算 的 基数 和 实际 的 基数 。 然 后 ， 
根据 这 两 个 基数 有 多 接近 ， 本 次 执行 与 三 个 桶 中 的 一 个 相关 联 (换言之 count 列 增加 了 )。 稍 后 ， 当 执 
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行 涉及 同一 个 游标 的 下 一 阶段 操作 时 ， 以 及 涉及 执行 在 这 三 个 桶 中 间 如 何 分 布 时 ， 一 个 游标 可 能 会 变 
成 绑 定 感知 的 或 非 感知 的 。 举 例 来 说 ， 当 低 效 的 执行 次 数 和 高 效 执行 次 数 一 样 多 时 ， 游 标 就 被 置 为 绑 
定 感知 的 。 接 下 来 的 例子 证 明了 这 点 ( 注意 ， 对 于 编号 0 的 子 游标 ， 高 效 的 执行 次 数 和 低 效 的 执行 次 
数 相同 )。 


SQL> SELECT child number, bucket id, count 
2 FROM v$sql cs histogram 
3 WHERE sql id = “asthlmx10aygn” 
4 ORDER BY child number, bucket id; 


CHILD NUMBER BUCKET_ID COUNT 
0 0 4 
0 1 1 
0 2 0 
1 0 1 
人 1 0 
业 2 0 
2 0 1 
2 nk 0 
2 2 0 


为 了 更 好 地 理解 如 何 使 用 v$sql_cs_histogram 视 图 的 内 容 ， 我 建议 你 用 adaptive_cursor sharing_ 
histogram.sql 中 的 脚本 做 以 下 几 种 情况 的 实验 。 

自 适应 游标 共享 有 两 个 主要 的 限制 。 第 一 ， 默 认 情况 下 ， 游 标 是 按照 绑 定 不 敏感 创建 的 。 第 二 ， 
对 于 给 定 的 游标 ， 绑 定 感知 不 是 持续 的 。 结 果 就 是 ， 在 一 个 游标 从 自 适应 游标 共享 中 获 益 之 前 ， 至 少 
有 一 次 执行 是 无 效率 的 ， 在 某 些 情况 下 甚至 有 多 次 执行 ( 当 曾 经 有 很 多 次 高 效 执行 时 ) 是 无 效率 的 。 
自 11.1.0.7 版 开始 ， 才 有 可 能 通过 指定 bind_aware 这 个 hint 来 避免 这 些 限 制 。 注意， 在 下 面 的 例子 中 ， 
两 个 子 游标 都 是 绑 定 敏感 的 ， 且 都 使 用 了 高 效 的 执行 计划 。 


S0L> EXECUTE <1d := 40; 
SQL> SELECT /*+ bind aware */ count(pad) FROM 七 WHERE id «< :id; 


COUNT(PAD) 


0 | SELECT STATEMENT | 
1 | SORT AGGREGATE | 
2 | TABLE ACCESS BY INDEX ROWID | 
3 | INDEX RANGE SCAN | 


SQL> EXECUTE :id := 990; 


中 这 个 词 在 书 中 未 翻译 ， 因 为 译 为 “提示 ”有 时 候 会 导致 将 其 原 有 含义 淹没 在 译文 中 。 一 一 译 者 注 


SQL> SELECT /*+ bind aware */ count(pad) FROM 七 WHERE id < :id; 


COUNT(PAD) 


0 | SELECT STATEMENT | 
| 1 | SORT AGGREGATE | 
2 | TABLE ACCESS FULL |T | 


SOL> SELECT child number, is bind sensitive, is bind aware, is shareable, plan hash value 
2 FROM v$sql 
3 WHERE sql id = 'f364ymn1ibbr4q' 
4 ORDER BY child number; 


CHILD NUMBER IS BIND SENSITIVE IS BIND AWARE IS SHAREABLE PLAN HASH VALUE 


oY Y ¥ 4270555908 
员 溢 Y Y 2966233522 


概括 起 来 ， 为 了 增加 查询 优化 器 产生 高 效 执行 计划 的 可 能 性 ， 就 不 应 该 使 用 绑 定 变量 。 绑 定 变量 
扫 视 可 能 会 有 帮助 。 然 而 ， 有 时 候 能 否 产生 高 效 的 执行 计划 只 是 运气 的 问题 。 唯 一 的 例外 是 从 11.1 版 
本 开始 ， 新 的 自 适应 游标 共享 能 自动 识别 出 问题 。 


3. 最 佳 实践 
任何 特性 都 应 该 仅 在 使 用 它 的 收益 比 损害 要 大 时 才 使 用 。 某 些 情况 下 很 容易 做 决定 。 例 如 ， 当 执 
行 一 个 没有 WHERE 条 件 的 SQL 语 句 ( 例如 简单 的 INSERT 语 名 ) 时 没有 理由 不 使 用 绑 定 变量 。 另 一 方面 ， 
当 被 绑 定 变量 扫 视 破坏 的 风险 较 高 时 , 无 论 如 何 也 不 应 该 使 用 绑 定 变量 。 尤 其 是 遇 到 下 面 三 种 情况 时 。 
口 当 查 询 优化 器 必须 检查 一 个 值 是 否 在 可 访问 值 的 范围 之 外 时 (也 就 是 比 列 中 最 小 值 小 或 比 最 
大 值 大 )。 
口 当 NHERE 条 件 中 的 谓词 是 基于 范围 条 件 的 (例如 ，HIREDATE > "2009-12-31" )。 
口 当 查 询 优化 器 使 用 直方 图 时 。 
因此 , 对 于 可 共享 的 游标 , 当 遇 到 以 上 三 种 情况 时 就 不 应 该 使 用 绑 定 变量 。 对 于 其 他 所 有 的 情况 ， 
就 没有 这 么 绝对 了 。 然 而 ， 最 好 考虑 以 下 两 种 主要 的 情况 。 
口 SQL 语句 处 理 少量 数据 : 每 当 处 理 较 少 的 数据 时 ， 硬 解析 的 时 间 可 能 会 接近 或 者 超过 执行 时 
间 。 在 这 种 情况 下 , 使 用 绑 定 变 量 从 而 避免 硬 解析 通常 是 必须 的 。 在 SQL 语句 预计 会 经 常 执行 
时 尤其 如 此 。 通 常 这 样 的 SQL 语句 用 于 数据 实体 系统 〈 一 般 是 OLTP 系 统 相关 的 )。 
口 SQL 语句 处 理 大 量 数据 : 每 当 处 理 大 量 数据 时 ， 硬 解析 时 间 通 常 比 执行 时 间 小 几 个 量 级 。 在 
这 种 情形 下 ， 使 用 绑 定 变 量 不 仅 对 于 整个 响应 时 间 是 无 关 紧 要 的 ， 同 时 也 增加 了 查询 优化 器 
产生 非常 低 效 的 执行 计划 的 风险 。 因 此 ， 不 应 该 使 用 绑 定 变量 。 通 常 ， 这 样 的 语句 用 来 做 批 
处 理 任务 ， 用 于 报表 用 途 ， 或 者 在 数据 仓库 环境 下 由 OLAP 应 用 和 BI 工 具 发 出 。 
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2.5 读 写 数据 块 


为 了 读 写 数据 文件 中 的 数据 块 ， 数 据 库 引擎 利 用 几 种 不 同 的 磁盘 IO 操作 (参见 图 2-4 )。 

口 远 辑 读 : 服务 进程 在 访问 一 个 缓冲 区 缓存 中 的 块 或 进程 私有 内 存 中 的 块 时 执行 逻辑 读 。 注 意 ， 
逻辑 读 既 用 于 读 ， 同 时 也 用 于 向 一 个 数据 块 写 数据 。 

口 缓冲 区 缓存 读 : 当 服 务 进程 需要 的 块 还 不 在 缓冲 区 缓存 时 执行 缓冲 区 缓存 读 。 所 以 它 会 打开 
数据 文件 ， 读 这 个 数据 块 ， 然 后 将 其 存储 在 缓冲 区 缓存 中 。 

口 DBWR 写 : 通常 情况 下 ,服务 进程 不 会 向 数据 文件 写 数 据 ， 它 们 只 修改 存储 在 缓冲 区 缓存 中 的 
块 。 然 后 由 数据 库 写 进程 ( 即 后 台 进 程 ) 负责 将 修改 的 块 ( 也 称 为 脏 块 ) 存储 到 数据 文件 中 。 

口 直接 路 径 读 : 在 某 些 情况 下 (在 第 13 章 和 第 15 章 中 详 述 )， 服 务 进程 能 够 直接 从 数据 文件 中 读 
取 数 据 块 。 当 服务 进程 使 用 这 种 方式 时 ， 数 据 块 会 直接 传输 至 进程 的 私有 内 存 而 非 加 载 至 组 
冲 区 缓存 内 。 

口 直接 路 径 写 : 在 某 些 情况 下 (在 第 15 章 中 详 述 )， 服 务 进 程 能 够 直接 向 数据 文件 写 人 数据 块 。 

在 不 必 区 分 那些 是 否 涉及 缓冲 区 缓存 的 磁盘 IO 操作 的 情况 下 ， 可 以 使 用 以 下 两 个 术语 。 

口 物理 读 包含 缓冲 区 缓存 读 和 直接 路 径 读 。 

口 物理 写 包 含 直 接 路 径 写 和 DBWR 写 。 


天 


图 2-4 数据 库 引擎 使 用 几 种 不 同类 型 的 MO 操作 


当 数据 文件 存储 在 一 台 Exadata 存 储 服务 器 上 时 ， 数 据 库 引擎 也 可 以 利用 第 六 种 磁盘 IO 操作 : 知 
能 扫描 ( smart sacn )。 简 言 之 ， 在 Exadata 系 统 上 ， 数 据 库 引擎 可 以 使 用 智能 扫描 蔡 代 直接 路 径 读 。 从 
数据 库 引 擎 的 角度 来 看 , 这 两 种 磁盘 IO 操作 的 显著 区 别 是 直接 路 径 读 返回 规则 的 块 , 而 智能 扫描 返回 
不 同 的 数据 结构 。 智 能 扫描 的 目标 是 降低 一 部 分 原本 应 由 数据 库 引 擎 向 存储 层 完成 的 工作 。 考 虑 到 这 


口 避免 在 Exadata 存 储 服 务 器 和 数据 库 实例 中 移动 不 相干 的 数据 。 
口 允许 Exadata 存 储 服务 器 避免 读 取 不 需要 的 磁盘 数据 。 
口 减少 Exadata 存 储 服务 器 的 CPU 密集 型 操作 ， 进 而 减少 数据 库 引 擎 的 CPU 使 用 率 。 


什么 是 Oracle Exadata 


Exadata 是 由 Oracle 设 计 的 数据 库 一 体 机 ,由 数据 库 服务 器 、Exadata 存 储 服务 器 、 拥 有 InfiniBand 
技术 的 光纤 存储 网 络 以 及 其 他 所 有 运行 Oracle 数 据 库 所 需 的 组 件 组 成 。 然 而 ，Exadata 并 不 仅仅 是 一 
套 硬件 解决 方案 。 当 Oracle 数 据 库 在 Exadata 硬 件 上 运行 时 ,设计 用 于 获取 更 好 性 能 的 特别 软件 特性 
就 启用 了 。 其 中 的 一 个 关键 设计 决策 就 是 ,将 部 分 本 应 由 数据 库 服 务 器 完成 的 工作 负载 转移 给 存储 
服务 器 。 
| 


2.6 ”检测 


正如 第 1 章 提 到 的 ， 每 个 应 用 程序 都 应 该 进行 检测 。 换 句 话 说， 问题 不 是 应 不 应 该 去 做 ， 而 是 应 
该 怎么 做 。 这 是 架构 师 在 新 的 应 用 程序 开发 之 初 就 应 做 出 的 重要 决定 。 虽 然 检 测 代 码 通 常 是 为 了 在 
异常 条 件 下 具体 化 应 用 程序 的 行为 而 实现 的 , 但 是 它 也 可 以 用 来 调查 性 能 问题 。 为 了 定位 性 能 问题 ， 
我 们 尤其 想 了 解 执行 过 哪些 操作 、 执 行 顺序 如 何 、 处 理 的 数据 有 多 少 、 这 些 操作 执行 了 多 少 次 以 及 
花费 了 多 长 时 间 。 在 某 些 情形 下 ( 例如 大 型 任务 )， 了 解 使 用 了 多 少 资源 也 是 有 帮助 的 。 由 于 在 调用 
级 别 或 者 链 路 级 别 的 信息 已 由 代码 探查 器 提供 ， 检 测 时 应 该 特别 关注 业务 相关 的 操作 以 及 各 个 组 件 
( 层 ) 之 间 的 交互 。 此 外 ， 如 果 一 个 请 求 需 要 在 同一 个 组 件 内 部 执行 复杂 的 处 理 ， 可 以 提供 处 理 过 程 
中 实施 的 主要 步骤 的 相应 时 间 。 换 句 话 说， 为 了 更 有 效 地 利用 检测 代码 ， 应 该 将 它 添加 到 代码 的 决 
策 性 位 置 上 。 我 强调 一 下 ， 如 果 没 有 响应 时 间 的 信息 ， 检 测 对 于 调查 性 能 问题 就 毫 无 意义 。 

我 们 来 看 一 个 例子 。 在 应 用 程序 JPetStore ( 在 第 1 章 中 简单 介绍 过 ) 中 ， 有 一 个 叫 作 Sign-on 登 入 
的 操作 ， 图 2-5 展 示 了 它 的 序列 图 。 基 于 这 个 图 ,检测 至 少 应 该 提供 如 下 这 些 信息 。 

口 从 servlet 给 出 响应 到 请 求 (FrameworkServlet ) 来 衡量 的 请 求 的 系统 响应 时 间 。 这 是 业务 相关 


的 操作 。 
口 SQL 语句 和 数据 访问 对 象 ( AccountDao ) 与 数据 库 之 间 交 互 的 响应 时 间 。 这 是 中 间 层 和 数据 库 
层 之 间 的 交互 。 


口 请 求 以 及 与 数据 库 的 交互 两 者 开始 和 结束 的 时 间 戳 。 


OD servlet 是 一 种 向 来 自 Web 客 户 端的 请 求 做 出 响应 的 Java 程 序 ， 运 行 于 J2EE 应 用 服务 器 中 
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EEC 


handleRequest 


getAccount 


1 
1 
1 
1 
' 
1 
1 
SELECT |! 


1 1 
1 
EE a i 1 
1 1 
1 1 


图 2-5 JPetStore 登 人 操作 的 序列 图 


通过 这 些 值 和 用 户 响应 时 间 ， 如 果 可 以 再 利用 应 用 程序 ， 就 可 以 轻易 使 用 手表 检测 它们 ， 从 而 就 
可 以 通过 类 似 图 1-7 的 方式 拆 分 响应 时 间 。 2 

在 实践 中 , 不 能 随意 在 你 想 要 的 位 置 添加 检测 代码 。 在 图 2-5 的 案例 中 , 你 有 两 个 问题 。 一 是 servlet 
( FrameworkServlet ) 是 由 Spring 框架 提供 的 class 文 件 。 因 此 ， 你 不 想 去 修改 它 。 二 是 数据 访问 对 象 
( AccountDao ) 只 不 过 是 在 持久 层 框架 ( 本 例 中 是 iBatis ) 之 前 使 用 的 一 个 接口 。 因 此 ， 你 也 不 能 向 它 
加 入 代码 。 对 于 第 一 个 问题 ， 可 以 通过 加 入 检测 代码 ， 从 而 创建 自己 的 servlet 继 承 FrameworkServlet 
来 解决 。 对 于 第 二 个 问题 ,为 了 方便 起 见 ， 可 以 决定 只 检测 持久 层 框架 的 调用 。 这 应 该 没 问 题 ， 因 为 
数据 库 本 身 已 经 经 过 检测 了 ， 所 以 ， 如 果 有 必要 ， 就 能 够 判定 持久 层 框 架 本 身 的 消耗 。 

现在 已 经 看 到 如 何 决 定 应 该 将 检测 代码 加 到 哪里 , 我 们 可 以 看 一 下 关于 如 何在 应 用 程序 代码 中 落 

它 的 具体 例子 。 随 后 ， 我 们 将 查看 Oracle 特 有 的 数据 库 调 用 的 检测 。 


2.6.1 应 用 程序 代码 


通常 ， 检 测 代码 都 是 通过 利用 已 经 可 用 的 日 志 框 架 来 实现 的 。 原 因 很 简单 : 写 一 个 快速 而 灵活 的 
日 志 框架 并 不 简单 。 因此 使 用 已 有 的 框架 可 以 节省 大 量 的 开发 时 间 。 事实 上 , 使 用 日 志 的 主要 缺点 是 ， 
不 恰当 的 实现 会 拖 慢 应 用 程序 。 为 了 避免 这 个 问题 ， 开 发 人 员 不 仅 应 该 限制 日 志 的 宛 长 ， 而 且 需 要 用 
一 个 高 效 的 日 志 框 架 实现 它 。 

Apache 日 志 服 务 项 目 ( Apache Logging Services Project”) 为 日 志 框 架 树 立 了 良好 的 范例 。 这 
个 项 目的 核心 是 log4j， 它 是 一 个 为 Java 写 的 日 志 框架 。 因 为 在 Java 上 的 成 功 ， 它 也 被 移植 到 其 他 的 
编程 语言 中 ， 如 C++、.NET、Perl 及 PHP 等 。 在 这 里 我 会 提供 一 个 基于 log4j 和 Java 的 例子 。 举 例 来 
说 ， 如 果 你 想 检 测 图 2-5 中 SignonController servlet 的 handleRequest 方 法 的 响应 时 间 ， 可 以 编写 如 
下 的 代码 : 


(GD 查看 http:/logging.apache.org 获 取 更 多 信息 。 
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public ModelAndView handleRequest(HttpServletRequest request, 
HttpServletResponse response) throws Exception 


if (logger == null) 


logger = Log4jLoggingHelper.getLog4jServerLogger(); 
} 


if (logger.isInfoEnabled()) 


long beginTimeMillis = System.currentTimeMillis(); 


ModelAndView ret = null; 
String username = request.getParameter("username"); 


// 处 理 请 求 的 代码 …… 
if (logger.isInfoEnabled()) 
{ 


long endTimeMillis = System.currentTimeMillis(); 
logger.info("Signon(" + username + ") response time " + 
(endTimeMillis-beginTimeMillis) + " ms"); 
} 


return ret; 


简单 来 说 ， 检 测 代 码 ， 也 就 是 粗 体 部 分 ， 会 在 方法 开始 时 获取 一 个 时 间 戳 ， 在 方法 结束 时 也 获取 
一 个 时 间 惟 ， 然 后 记录 一 条 信息 ， 其 中 包含 用 户 的 名 称 以 及 执行 方法 花费 的 时 间 。 开 始 的 时 候 ， 它 还 
会 检查 日 志 记 录 器 是 否 已 经 被 初始 化 了 。 注 意 ，Log4jLoggingHelper 类 针对 Oracle WebLogic Server， 
而 非 0g4j。 这 是 测试 时 使 用 的 。 虽 然 这 段 代码 简单 明了 ， 但 还 是 有 下 面 几 点 需要 我 们 注意 。 
口 开始 检测 时 间 ， 本 例 中 是 通过 在 检测 代码 的 最 开始 调用 currentTimeMillis 方 法 。 你 永远 不 知 
道 会 遇 到 什么 情况 ， 甚 至 初始 化 代码 也 会 消耗 时 间 。 
口 日 志 框 架 应 该 提供 不 同 级 别 的 消息 。 在 log4j 中 有 以 下 级 别 可 用 ( 按 宛 长 度 排 序 ): fatal、 error、 
warning、information 和 debug。 通过 调用 下 列 方法 之 一 来 设置 级 别 : fatal、 error、 warn、info 
和 debug。 换 言 之 ， 每 个 级 别 都 有 它 对 应 的 方法 。 通 过 将 消息 放 入 不 同 的 级 别 ， 你 可 以 通过 启 
用 和 禁用 指定 的 级 别 明确 选择 日 志 的 元 长 度 。 如 果 你 想 在 调查 某 个 问题 时 仅 启用 部 分 检测 代 
码 ， 这 将 会 非常 有 用 。 
口 即使 日 志 程 序 知道 启用 了 哪个 日 志 级 别 , 也 最 好 不 要 调用 日 志方 法 。 以 info 为 例 , 如 果 那 个 指 
定 级 别 的 日 志 没有 启用 ， 就 尤其 要 避免 消息 构建 的 开销 ( 以 及 随 之 而 来 的 调用 垃圾 回收 )。 通 
常会 调用 像 isInfoEnabled 这 样 的 方法 来 检查 指定 级 别 的 日 志 是 否 打开 ， 如 果 有 必要 再 调用 日 
志方 法 ， 这 样 要 快 得 多 。 这 样 做 可 以 导致 巨大 的 差别 。 举 例 来 说 ， 在 我 的 测试 服务 器 上 ， 调 
用 isInfoEnabled 大 概 花费 7 纳 秒 ， 而 调用 info 方 法 并 提供 之 前 代码 段 中 的 参数 花费 大 约 265 纳 
秒 ( 我 使 用 LoggingPerf.java 中 定义 的 类 来 检测 这 些 统计 信息 )。 另 一 种 减 小 检测 开销 的 技术 
是 在 正式 编译 时 移 除 日 志 代 码 。 但 这 不 是 一 个 首选 的 技术 ， 因 为 通常 情况 下 在 需要 检测 时 是 
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不 可 能 动态 重新 编译 该 代码 的 。 进 一 步 讲 ， 正 如 你 所 看 到 的 ,一 行 不 产生 任何 消息 的 检测 代 
码 的 开销 真 的 很 小 。 

口 在 这 个 例子 中 , 产生 的 消息 可 能 是 类 似 Signon(JPS1907) response time 24 ms 这 样 的 内 容 。 这 对 
人 类 是 友好 的 ， 但 如 果 你 计划 将 消息 传递 给 另 一 个 程序 用 于 检查 服务 等 级 协议 ， 像 XML 或 者 
JSON 这 样 的 更 结构 化 的 形式 可 能 会 更 合适 一 些 。 


2.6.2 ”数据 库 调用 


本 节 将 讨论 如 何 正确 检测 数据 库 调 用 , 以便 为 数据 库 引 擎 提供 关于 它们 将 要 执行 的 应 用 程序 上 下 
文 的 信息 。 要 意识 到 这 种 类 型 的 检测 与 你 在 上 一 节 中 看 到 的 有 很 大 不 同 。 事 实 上 ， 数 据 库 调用 不 仅 应 
该 能 够 像 应 用 程序 的 任何 其 他 部 分 一 样 进行 检测 ， 而 且 数据 库 自 身 也 能 够 生成 关于 它 执 行 的 数据 库 调 
用 的 详细 信息 。 你 会 在 本 书 第 二 部 分 了 解 到 更 多 内 容 。 这 里 描述 的 这 种 类 型 的 检测 目标 是 ， 向 数据 库 
引擎 提供 关于 使 用 它 的 用 户 或 者 应 用 程序 的 信息 。 这 样 做 是 有 必要 的 ， 因 为 数据 库 引 擎 通常 只 有 少量 
关于 应 用 程序 代码 、 会 话 以 及 最 终 用 户 之 间 的 关系 的 信息 , 甚至 根本 没有 , 考虑 如 下 两 个 常见 的 情形 。 
口 数据 库 引 擎 并 不 知道 应 用 程序 代码 的 哪个 部 分 正在 通过 会 话 执 行 SQL 语 句 。 例如 , 数据 库 引 擎 
对 于 究 况 是 哪个 模块 、 类 或 者 报表 正 通 过 给 定 的 会 话 执行 一 个 特定 的 SQL 语 句 毫 无 线索 。 

口 如 果 连 接 池 是 由 一 名 技术 用 户 打开 的 ， 而 代理 用 户 没 有 使 用 它 ， 那 么 当 应 用 程序 通过 该 连接 
池 连 接 到 数据 库 引 擎 时 ， 最 终 用 户 的 身份 验证 通常 都 是 由 应 用 程序 自己 执行 的 。 因 此 ， 数 据 
库 引 警 会 忽略 是 哪个 最 终 用 户 在 使 用 哪个 会 话 。 

基于 这 些 原因 ， 数 据 库 引擎 提供 了 动态 关联 一 个 数据 库 会 话 的 如 下 特性 的 机 会 。 

口 客户 端 标识 符 ( Client identifier ): 用 于 识别 客户 端的 64 字 节 长 度 的 字符 串 , 尽管 不 是 非常 明确 。 

口 客户 端 信息 ( Client information ): 用 于 描述 客户 端的 64 字 节 长 度 的 字符 串 。 

口 模块 名 称 ( Module name ): 用 于 描述 会 话 中 正在 使 用 的 模块 名 称 的 48 字 节 长 度 的 字符 串 。 

口 动作 名 称 ( Action name ): 用 于 描述 正在 处 理 的 动作 的 32 字 节 长 度 的 字符 串 。 


警告 ”对 于 通过 数据 库 链 接 打 开 的 会 话 ， 只 有 客户 端 标识 符 会 自动 传播 到 远 端 的 会 话 上 。 因 此 对 于 
其 他 特性 ， 有 必要 显 式 地 设 定 。 


客户 端 特性 的 值 通过 v$session 视 图 和 userenv 上 下 文 环境 体现 。 下 面 的 例子 是 对 session_ 
attributes.sql 脚 本 生成 的 输出 的 一 段 摘录 ， 展 示 了 如 何 查 询 它 们 。 
SQL> SELECT sys context('userenv','client identifier') AS client identifier， 
2 sys_context('userenv','client info') AS client info, 
= Sys_context('userenv', 'module') AS module name, 


4 sys_context('userenv','action') AS action name 
5 FROM dual; 


CLIENT IDENTIFIER CLIENT_INFO MODULE NAME ACTION NAME 


helicon.antognini.ch Linux x86 64 session info.sql test session information 


SQOL> SELECT client identifier, 
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2 client_ info, 

3 module AS module name, 

4 action AS action name 

5 FROM v$session 

6 WHERE sid = sys context('userenv','sid'); 


CLIENT_IDENTIFIER CLIENT INFO MODULE NAME ACTION NAME 


helicon.antognini.ch Linux x86 64 session info.sql test session information 

注意 ， 其 他 显示 SQL 语句 的 视图 也 包含 nodule 和 action 列 ， 例 如 v$sql。 提 醒 一 句 : 这 些 特性 关联 
到 具体 的 会 话 ， 但 是 一 个 给 定 的 SQL 语句 可 以 被 多 个 会 话 共享 从 而 拥有 不 同 的 模块 名 称 和 动作 名 称 : 
这 些 由 动态 性 能 视图 显示 的 值 是 第 一 个 解析 SQL 语句 的 会 话 在 做 硬 解 析 时 设置 的 。 如 果 你 不 加 小 心 ， 
可 能 会 误 入 歧途 。 

现在 你 已 经 看 到 了 什么 是 可 用 的 , 我 们 来 看 一 下 如 何 设置 这 些 值 。 第 一 个 方法 一 一 PL/SQL, 是 唯 
一 一 个 不 需要 依赖 连接 数据 库 的 接口 的 方法 , 因此 它 可 以 用 于 大 多 数 情形 中 。 接 下 来 的 四 个 一 一 OCI、 
JDBC、ODPNET 和 PHP, 则 仅 可 以 通过 指定 的 接口 程序 使 用 。 它们 的 主要 优势 是 这 些 值 会 加 入 到 下 一 
次 数据 库 调 用 中 而 不 会 产生 额外 的 往返 操作 , 而 调用 PL/SQL 却 会 。 因 此 为 它们 设置 这 些 特性 的 负载 可 
以 忽略 不 计 。 


1. PL/SQL 

你 需要 使 用 dbms_session 包 中 的 存储 过 程 set_identifier 来 设置 客户 端 标 识 符 。 在 某 些 情况 下 , 比 
如 客户 端 标识 符 是 在 全 局 上 下 文 环境 以 及 连接 池 中 使 用 时 ， 可 能 有 必要 清除 已 与 给 定 会 话 关联 的 值 。 
如 果 是 这 样 ， 就 可 以 用 clear identifier 这 个 存储 过 程 。 

要 设置 客户 端 信息 、 模 块 名 称 以 及 动作 名 称 ， 可 以 使 用 dbms_application_info 包 中 对 应 的 
set_client info、set_module 和 set_action 存 储 过 程 。 为 简单 起 见 ，set_module 存 储 过 程 不 仅 接受 模块 
名 称 ， 而 且 也 接受 动作 名 称 。 

下 面 的 PL/SQL 代 码 块 摘自 脚本 session attributes,sql， 它 展示 了 这 样 一 个 例子 。 


BEGIN 
dbms_session.set identifier(client id=>'helicon.antognini.ch'); 
dbms application info.set client info(client info=>'Linux x86 64'); 
dbms_application info.set module(module name=>'session info.sql', 
action name=>'test session information ); 
END; 


2. OCI 

为 了 设置 这 四 个 特性 ， 你 可 以 使 用 0CIAttrset 函 数 。 第 三 个 参数 指定 特性 的 值 。 第 五 个 参数 借助 
于 下 列 常量 中 的 一 个 来 指定 要 设置 哪个 特性 。 

DQ OCIT ATTR CLIENT IDENTIFIER 

DOCI ATTR CLIENT INFO 

DQ OCT ATTR MODULE 

口 0CI ATTR_ACTION 

下 面 的 代码 片段 , 是 session_attributes.c 文 件 中 的 一 段 摘录 , 展示 了 如 何 调用 0CIAttrSet 函 数 来 
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设置 客户 端 标识 符 。 

text client id[64] = "helicon.antognini.ch"; 

OCIAttrSet(ses, // 会 话 向 柄 
OCI HTYPE SESSION, // 被 修改 的 句柄 类 型 
client id, // 特性 的 值 
strlen(client id)， // 特性 值 的 大 小 
OCIT ATTR_CLIENT IDENTIFIER， // 要 设置 的 特性 
err); // 错误 和 句柄 

3. JDBC 


JDBC 有 两 种 方式 设置 会 话 的 特性 。 传 统 方式 是 使 用 Oracle 扩 展 功能 ， 而 现代 方式 是 基于 标准 的 
JDBC 应 用 编程 接口 。 现 代 方 式 在 Oracle 提 供 的 12.1 版 的 JDBC 驱 动 中 可 用 。 因为 这 种 方式 是 基于 和 传统 
方式 相同 的 协议 ， 也 可 以 和 10.2、11.1 及 11.2 版 本 的 数据 库 一 起 使 用 。 注 意 ， 从 12.1 版 本 开始 ， 传 统 方 
式 被 弃 用 了 - 


@ 传统 方式 

为 了 设置 客户 端 标识 符 、 模 块 名 称 和 动作 名 称 ， 可 以 用 由 0racleConnection 接 口 提供 的 
setEndToEndMetrics 方 法 。 没 有 提供 对 客户 端 信息 设置 的 支持 。 通 过 字符 串 数 组 向 方法 传递 一 个 或 多 
个 特性 。 数 组 中 的 位 置 由 以 下 常量 定义 ， 用 于 确定 设置 哪个 特性 : 

口 END_ TO END CLIENTID INDEX 

口 END TO _ END MODULE INDEX 

DQ END TO END ACTION INDEX 

下 面 的 代码 片段 是 SessionAttributes.java 文 件 的 一 段 摘录 ， 展 示 了 如 何 定义 包含 特性 的 数组 以 
及 如 何 调用 setEndToEndMetrics 方 法 : 

metrics = new String[OracleConnection.END TO_END STATE INDEX MAX]; 

metrics[OracleConnection.END TO END CLIENTID INDEX] = "helicon.cha.trivadis.com"; 

metrics[OracleConnection.END TO END MODULE INDEX] = "SessionAttributes.java"; 


metrics[OracleConnection.END TO END ACTION INDEX] = "test session information"; 
((OracleConnection)connection).setEndToEndMetrics(metrics, (short)0); 


@ 现代 方式 

为 设置 客户 端 标识 符 、 模 块 名 称 以 及 动作 名 称 ， 你 可 以 使 用 Connection 接 口 提供 的 setClientInfo 
方法 。 不 提供 设置 客户 端 信息 的 支持 。setClientInfo 方 法 接受 两 个 字符 串 参 数 : 特性 的 名 称 和 值 。 你 
必须 按 如 下 值 指定 特性 名 称 : 

口 0CSID.CLIENTID 

口 0CSID.MODULE 

口 0CSID.ACTION 

下 面 的 代码 片段 来 自 于 SessionAttributes12c.java 文 件 中 的 一 段 摘录 ， 展 示 了 如 何 通过 
setClientInfo 设 置 特性 ， 

connection.setClientInfo("OCSID.CLIENTID", "helicon.cha.trivadis.com"); 


connection. setClientInfo("OCSID.MODULE", "SessionAttributes12c.java"); 
connection.setClientInfo("OCSID.ACTION", "test session information"); 
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4. ODP.NET 

要 设置 这 四 个 特性 ， 可 以 使 用 0racleConnection 类 的 ClientId 、ClientInfo 、ModuleName 和 
ActionName 等 属性 。 注 意 除 了 ClientId 属 性 ， 其 余 的 仅 从 11.1.0.6.20 版 本 起 才 可 以 使 用 。 为 了 防止 堆积 
的 会 话 接手 这 些 设置 , 属性 的 值 会 在 调用 OracleConnection 类 的 Close 或 Dispose 方 法 时 设置 为 nul1。 下 
面 的 代码 片段 是 来 自 SessionAttributes.cs 文 件 的 摘录 ， 展 示 了 如 何 设置 这 些 属 性 : 


connection.ClientId = "helicon.antognini.ch"; 
connection.ClientInfo = "Linux x86 64"; 

connection ModuleName = "SessionAttributes.cs"; 
connection.ActionName = "test session information"; 


5. PHP 
要 设置 这 四 个 特性 ， 请 使 用 PECL OCI8 扩 展 中 提供 的 函数 。 每 个 函数 接受 两 个 参数 ( 连接 和 特性 
作为 输入 ,并且 返回 一 个 Boolean 型 值 (成功 时 为 TRUE， 失 败 时 为 FALSE )。 这 四 个 函数 如 下 所 示 : 


DQ oci set client identifier 


. 


DQ oci set client info 
DQ oci set module name 
DQ oci set action 


下 面 的 代码 片段 是 来 自 session attributes.php 脚 本 的 一 段 摘录 ， 展 示 了 如 何 设置 所 有 的 特性 : 


oci set client identifier($connection, "helicon.antognini.ch"); 
oci set client info($connection, "Linux x86 64"); 

Oci set module name($connection, "session attributes.php"); 

oci set action($connection, "test session information"); 


注意 ， 这 些 函 数 仅 在 同时 符合 以 下 两 个 条 件 时 才 可 用 : OCI8 的 版 本 为 1.4 及 以 上 ，OCI8 与 10.1 及 
以 上 版 本 的 客户 端 库 相 关联 了 


2.7 小 结 


本 章 描述 了 当 数 据 库 引擎 解析 和 执行 SQL 语句 时 实施 的 操作 ， 着 重 讨 论 了 与 使 用 绑 定 变量 有 关 的 
正 反 两 方面 的 理由 。 此 外 ， 还 介绍 了 常用 的 术语 并 描述 了 如 何 检 测 应 用 程序 代码 和 数据 库 调用 。 

本 书 第 二 部 分 将 致力 于 回答 图 1-4 抛 出 的 前 两 个 问题 : 

口 时 间 是 在 哪里 消耗 的 

口 时 间 是 如 何 消耗 的 

简单 来 说 , 第 二 部 分 中 的 三 章 介 绍 了 查 明 问 题 所 在 以 及 查 明 导致 问题 的 原因 的 相关 方法 。 因 为 你 
在 修复 性 能 问题 上 没有 退路 了 ， 所 以 必须 正确 回答 这 些 问题 。 如 果 你 不 知道 引起 问题 的 原因 ， 自 然 就 
不 可 能 修复 这 个 问题 。 


识 别 


让 我 们 把 问题 解决 掉 ， 不 要 让 猜测 使 它 变 得 复杂 。” 


Eugene F. Kranz 


当 程序 出 现 性 能 问题 时 ， 很 显然 要 做 的 第 一 件 事 就 是 识别 导致 问题 的 根源 。 不 幸 的 是 ， 这 
往往 是 麻烦 的 开始 。 在 一 个 典型 的 案例 中 ， 当 所 有 人 都 在 寻找 性 能 问题 的 根源 时 ， 开 发 人 员 开 
始 抱怨 数据 库 性 能 差 ， 而 数据 库 管 理 员 则 一 方面 抱 她 开发 人 员 滥 用 数据 库 ， 另 一 方面 又 抱怨 存 
储 子 系统 管理 员 ， 理 由 是 昂贵 的 硬件 并 没有 带 来 更 好 的 性 能 。 并 且 随 着 应 用 的 复杂 度 和 基础 设 
施 支持 的 增加 ， 这 种 互相 埋怨 的 混乱 局 面 更 是 一 发 不 可 收拾 。 

第 二 部 分 的 章节 旨 在 介绍 数据 库 的 一 些 关 键 特性 ， 利 用 它们 可 以 找 出 在 数据 库 内 部 时 间 消 
耗 在 了 哪里 以 及 消耗 的 方式 。 在 阅读 这 些 章节 时 ， 请 记 住 第 工 章 的 建议 ， 仅 当 端 到 端的 响应 时 
间 数 据 表明 数据 库 层面 可 能 存在 问题 时 ， 才 收集 数据 库 引 擎 执行 时 的 详细 信息 。 否 则 ， 你 可 能 
会 进行 错误 的 分 析 。 如 果 你 分 析 错 误 ， 那么 在 诊断 故障 时 ， 就 很 可 能 无 法 判断 出 导致 性 能 问题 
的 原因 。 首 先 要 确定 问题 是 出 现在 数据 库 层面 ， 然 后 利用 这 部 分 的 内 容 来 具体 操作 。 

下 一 步 要 考虑 的 是 ， 当 处 理性 能 问题 时 ， 是 否 能 任意 地 重 现 问题 。 如 果 可 以 ,那么 事情 会 
变 得 很 简单 。 如 果 能 重 现 问 题 ， 那 么 应 该 很 容易 就 能 找 出 问题 所 在 ， 这 在 第 3 章 会 讲 到 。 如 果 
问题 不 能 随意 重 现 , 那么 就 会 有 两 个 选择 :等 待 问题 再 次 出 现 , 或 者 查找 历史 性 能 指标 的 知识 库 。 
这 两 种 方式 会 分 别 在 第 4 章 和 第 5 章 中 介绍 。 

此 外 ,无 论 能 否 重 现 问 题 ， 都 必须 找 出 最 耗 时 的 SQL 或 者 PL/SQL 代码 调用 。 然 后 ， 针 对 
每 条 耗 时 的 语句 ， 应 该 收集 任何 可 以 帮助 诊断 问题 的 附加 信息 。 

这 些 附加 信息 通常 包括 : 执行 计划 、 关 键 运 行 时 统计 “( 比如 已 处 理 的 行 数 和 CPU 使 用 率 的 
数量 ) 以 及 已 经 历 的 等 待 事件 ;第 二 部 分 只 讲 了 如 何 收集 这 些 信息 ,并 未 介绍 如 何 处 理 这 些 信息 。 
第 三 部 分 和 第 四 部 分 会 对 如 何 处 理 这 些 信息 详细 讲解 。 


QD 引 自 朗 - 霍华德 执导 的 电影 《阿波 岁 13 号 > 这 旬 话 就 出 现在 那 句 著名 的 “休斯顿 ， 我 们 直到 了 麻烦 ”( Houston, 
we have a problem ) 之 后 大 约 3 分 钟 处 。 
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当 你 的 分 析 指 向 几 条 SQL 语句 或 几 行 PL/SQL 代码 ， 会 发 现 部 分 程序 需要 优化 ， 并 上 且 可 以 
很 简单 地 解决 它 。 否 则 ， 大 量 SQL 语句 或 者 庞大 的 PL/SQL 代码 导致 的 过 长 响应 时 间 ， 往 往 意 
味 着 存在 设计 问题 。 这 时 彻底 重新 设计 有 时 是 必要 的 。 如 果 设 计 没有 问题 ， 那 么 很 可 能 是 运行 
程序 的 服务 器 性 能 不 足 造 成 的 。 

第 二 部 分 的 最 终 目 标 是 针对 性 能 差 的 程序 介绍 并 使 用 一 种 找到 瓶颈 的 方法 ， 而 不 是 仅仅 靠 
猜测 。 这 个 目标 还 包括 收集 在 第 三 部 分 和 第 四 部 分 需要 处 理 的 基本 信息 。 


当 一 个 程序 出 现 问题 ， 想 要 重 现 问题 最 有 效 的 办 法 就 是 利用 有 效 跟 踪 和 剖析 特性 来 定位 问题 。 首 
先 ， 把 问题 分 为 以 下 三 类 。 

口 数据 库 引 擎 将 大 量 时 间 花 费 在 执行 SQL 语句 上 。 

口 数据 库 引 擎 将 大 量 时 间 花 费 在 执行 PL/SQL 代 码 上 。 

口 数据 库 引 擎 (几乎 ) 空闲 。 换 句 话 说， 瓶颈 不 在 数据 库 层 。 

要 将 问题 分 类 ， 首 先 要 从 跟踪 数据 库 调 用 开始 。 如 果 分 析 指 向 SQL 语句 ， 那 么 最 初 对 问题 进行 分 
类 所 使 用 的 跟踪 文件 已 经 包含 了 所 有 必要 的 信息 。 如 果 问 题 出 在 PL/SQL 代 码 ， 则 应 该 剖析 PL/SQL 代 
码 。 和 否则 ， 问 题 就 不 在 数据 库 层 那么 分 析 应 该 继续 剖析 数据 库 引擎 执行 之 外 的 应 用 代码 。 

本 章 目标 不 仅仅 是 介绍 Oracle 数 据 库 提供 的 跟踪 和 前 析 功 能 ， 而 且 还 会 给 出 你 分 析 问 题 时 所 使 用 
的 工具 的 示例 。 最 后 ， 本 章 会 展示 这 些 工具 如 何 帮 助 你 快速 、 高 效 地 定位 性 能 问题 。 
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当 性 能 瓶颈 出 现在 数据 库 层 时 ， 就 更 应 该 关注 应 用 与 数据 库 引擎 的 交互 。Oracle 数 据 库 是 一 款 高 
度 工 具 化 的 软件 ， 多 亏 有 了 SQL 跟踪 ( SQL trace )， 它 提供 的 跟踪 文件 不 仅 包含 执行 的 SQL 语句 列表 ， 
同时 也 包含 了 这 些 语句 处 理 时 的 深度 性 能 指标 。 

图 3-1 展 示 了 涉及 跟踪 数据 库 调用 时 必 不 可 少 的 阶段 。 后 续 几 节 , 伴随 对 SQL 跟踪 的 解释 ,会 详细 
讨论 每 一 个 阶段 。 


Dearie 》 ear ) seit > wm) 本 其 =》 


图 3-1 跟踪 数据 库 调 用 时 必 不 可 少 的 阶段 


3.1.1 ”SQL 跟踪 


第 2 章 提 到 过 ， 要 处 理 SQL 语 句 ， 数 据 库 引擎 ( 尤其 是 SQL 引擎 ) 会 执行 数据 库 调 用 ( 例如 解析 、 
执行 和 获取 )。 图 3-2 总 结 了 对 于 每 个 数据 库 调 用 ，SQL 引 警 可 以 执行 以 下 操作 : 
口 使 用 CPU 自己 处 理 这 些 调 用 ; 
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口 使 用 其 他 资源 〈 比如 磁盘 ); 或 者 
口 不 得 不 通过 一 个 同步 点 来 保证 数据 库 引 擎 的 多 用 户 处 理 能 力 ( 比如 站 )。 
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图 3-2 SQL 引擎 与 其 他 组 件 间 交 互 的 顺序 图 


SQL 跟踪 的 目的 有 两 个 : 首先 ， 为 分 解 服务 时 间 与 等 待 时 间 之 间 的 响应 时 间 提 供 信息 ; 其 次 ,为 
使 用 的 资源 和 同步 点 提供 详细 信息 。 所 有 关于 SQL 引擎 与 其 他 组 件 间 的 交互 信息 都 会 保存 在 跟踪 文件 
里 。 请 注意 ,在 图 3-2 中 ，CPU、 资 源 X 和 同步 点 Y 的 属性 都 是 人 工 的 。 其 原因 是 为 了 展示 每 个 调用 可 
能 会 以 不 同 的 方式 使 用 数据 库 引 擎 。 
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尽管 本 章 后 续 部 分 还 会 介绍 更 多 的 细节 ， 但 让 我 们 暂时 先 看 一 个 由 SQL 跟踪 提供 的 信息 ， 该 信息 
可 以 使 用 工具 抽取 出 来 ( 这 里 使 用 TKPROF )。 它 包含 了 SQL 语句 的 文本 、 一 些 执行 统计 、 处 理 SQL 时 
发 生 的 等 待 事件 ， 以 及 解析 阶段 的 信息 ， 例 如 生成 执行 计划 。 请 注意 ， 这 些 信息 是 由 程序 执行 的 每 条 
SQL 语 句 和 数据 库 引 擎 自身 递归 调用 产生 的 。 


SELECT CUST_ID, EXTRACT(YEAR FROM TIME ID), SUM(AMOUNT SOLD) 
FROM SALES 

WHERE CHANNEL ID = ;B1 

GROUP BY CUST_ID, EXTRACT(YEAR FROM TIME ID) 


call count cpu elapsed disk query current TOWS 
Parse 1 0.00 0.00 0 0 0 0 
Execute 1 0.00 0.00 0 0 0 0 
Fetch 164 0.84 1.27 3472 1781 0 16348 
total 166 0.84 1:28 3472 1781 0 16348 


Misses in library cache during parse: 1 

Misses in library cache during execute: 1 
Optimizer mode: ALL ROWS 

Parsing user id: 77 (SH) (recursive depth: 4) 
Number of plan statistics captured: 1 


Rows (1st) Rows (avg) Rows (max) Row Source Operation 


16348 16348 16348 HASH GROUP BY 
540328 540328 540328 PARTITION RANGE ALL PARTITION: 1 28 
540328 540328 540328 TABLE ACCESS FULL SALES PARTITION: 1 28 


Elapsed times include waiting on following events: 


Event waited on Times Waited Max. Wait Total Waited 
Disk file operations 1/0 2 0.00 0.00 
db file sequential read 29 0.00 0.00 
direct path read 70 0.00 0.00 
asynch descriptor resize 16 0.00 0.00 
direct path write temp 1699 0.02 0.62 
direct path read temp 1699 0.00 0.00 


之 前 提 到 ， 上 面 的 例子 是 由 工具 TKPROF 生 成 的 。 这 并 不 是 SQL 跟踪 生成 的 输出 。 实 际 上 ，SQL 
跟踪 输出 文本 文件 ， 存储 组 件 间 交互 的 原始 信息 。 这 有 一 份 与 上 面 的 例子 相关 的 跟踪 文件 节选 。 通 常 
情况 下 ， 对 应 每 一 个 调用 或 者 等 待 ， 跟 踪 文 件 中 至 少 会 存在 一 行 代 码 。 


PARSING IN CURSOR #140105537106328 len=139 dep=1 uid=77 oct=3 1id=93 tim=1344867866442114 
hv=2959931450 ad="706df490' sqlid='arc3zqqs6ty1u' 

SELECT CUST_ID, EXTRACT(YEAR FROM TIME ID), SUM(AMOUNT SOLD) FROM SALES WHERE CHANNEL ID = :B1 
GROUP BY CUST _ ID, EXTRACT(YEAR FROM TIME ID) 

END OF STMT 

PARSE #140105537106328:Cc=1999,e=1397,p=0,Cr=0, Cu=0, mis=1,1=0, dep=1,0g=1, plh=0, tim=1344867866442113 
BINDS #140105537106328: 
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Bind#O 

oacdty=02 mxl=22(21) mxlc=00 mal=00 scl=00 pre=00 

oacflg=03 fl2=1206001 frm=00 csi=00 siz=24 off=0 

kxsbbbfp=7f6cdcc6c6e0 bln=22 avl=02 flg=05 

value=3 
EXEC #140105537106328:c=7000,e=7226,p=0, Cr=0, Cu=0,mis=1,7=0, dep=1,0g=1, plh=3604305554, 
tim=1344867866449493 
WAIT #140105537106328: nam= "Disk file operations 1/0' ela= 45 FileOperation=2 fileno=4 filetype=2 
obj#=69232 tim=1344867866450319 
WAIT #140105537106328: nam='db file sequential read' ela= 59 file#=4 block#=5009 blocks=1 obj#=69232 
tim=1344867866450423 


FETCH #140105537106328:c=0,e=116,p=0,cr=0, CUu=0,mis=0,r=48,dep=1,0g=1,plh=3604305554, 
tim=1344867867730523 

STAT #140105537106328 id=1 cnt=16348 pid=0 pos=1 obj=0 op="'HASH GROUP BY (cr=1781 pr=3472 pw=1699 
time=1206229 Us cost=9220 size=4823931 Card=229711) 

STAT #140105537106328 id=2 cnt=540328 pid=1 pos=1 obj=0 op="'PARTITION RANGE ALL PARTITION: 1 28 
(cr=1781 pr=1773 pw=0 time=340163 us cost=1414 size=4823931 card=229711)" 

STAT #140105537106328 id=3 cnt=540328 pid=2 pos=1 obj=69227 op=" TABLE ACCESS FULL SALES PARTITION: 1 
28 (cr=1781 pr=1773 pw=0 time=280407 US cost=1414 size=4823931 card=229711)" 

CLOSE #140105537106328:c=0,e=1,dep=1,type=3,tim=1344867867730655 


在 上 面 节 选 的 部 分 里 ， 一些 描 述 此 类 信息 的 标记 以 粗 体 突出 显示 出 来 。 

口 PARSING IN CURSOR 和 END OF STMT 之 间 的 部 分 就 是 SQL 语 句 的 文本 。 

口 PARSE 、EXEC、FETCH 和 CLOSE 分 别 表示 解析 、 执 行 、 获 取 和 结束 调用 。 

口 BINDS 表 示 绑 定 变量 的 定义 和 值 。 

口 WAIT 表 示 处 理 过 程 中 发 生 的 等 待 事件 。 

口 STAT 表 示 已 发 生 的 执行 计划 和 关联 的 统计 信息 。 

你 可 以 在 Oracle Support 文 档 Jnterpreting Raw SOL 7R4CE output ( 39817.1 ) 中 找到 关于 跟踪 文件 


格式 的 简单 描述 。 如 果 对 这 个 话题 感 兴 趣 ， 想 了 解 详细 描述 和 相关 讨论 ， 可 以 阅读 Millsap 的 著作 The 
Method R Guide to Mastering Oracle Trace Data ( CreateSpace，2013 )。 


在 数据 库 内 部 ，SQL 跟 踪 基于 调试 事件 10046。 表 3-1 描 述 了 可 支持 的 级 别 ， 这 代表 在 跟踪 文件 里 


可 获得 的 信息 量 。 将 SQL 跟 踪 设 置 为 高 于 等 级 1 时 ，SQL 跟 踪 也 被 称 为 扩展 SQL 跟 踪 。 


级 


表 3-1 10046 调 试 事件 级 别 
别 描 述 

0 调试 事件 被 禁止 

1 调试 事件 启用 。 针 对 每 个 处 理 的 数据 库 调 用 ， 都 会 给 出 以 下 信息 : SQL 语句 、 响 应 时 间 、 服 务 时 间 、 处 
理 的 行 数 、 逻 辑 读 数 、 物 理 读数 和 物理 写 数 、 执 行 计 划 以 及 一 小 部 分 附加 信息 
在 10.2 版 本 中 ， 执 行 计划 只 有 在 与 其 关联 的 游标 被 关闭 后 才 会 写 入 到 跟踪 文件 中 。 与 执行 计划 关联 的 统 
计 信 息 , 来自 多 次 执行 的 值 聚合 
从 版 本 11.1 起 ， 执 行 计划 在 每 个 游标 第 一 次 执行 时 写 入 跟踪 文件 。 与 执行 计划 关联 的 统计 信息 ， 仅 仅 来 
自 第 一 次 执行 的 值 


4 同 级 别 1， 附 加 信息 是 绑 定 变量 。 主 要 是 数据 类 型 及 其 精度 和 针对 每 次 执行 使 用 的 值 
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( 续 ) 
级 别 描 述 
8 同 级 别 1， 附 加 等 待 时 间 的 详细 信息 。 对 于 每 次 处 理 时 经 历 的 等 待 事件 ， 会 给 出 一 些 信 息 ， 包 括 等 待 事 
牛 名称 、 持 续 时 间 和 一 些 附加 参数 ， 用 来 确认 被 等 待 的 资源 
16 同 级 别 1， 每 次 执行 后 的 执行 计划 信息 也 会 写 人 跟踪 文件 。 仅 对 版 本 11.1 及 以 上 版 本 有 效 
32 同 级 别 1， 但 不 包含 执行 计划 信息 。 仅 对 版 本 11.1 及 以 上 版 本 有 效 
04 同 级 别 1， 第 一 次 执行 之 后 的 执行 计划 信息 也 可 能 会 被 写 信 。 条 件 是 最 后 一 次 写 人 执行 计划 信息 后 ， 某 
个 游标 还 会 至 少 占用 一 分 钟 的 数据 库 时 间 。 这 个 级 别 适用 于 两 种 情况 ，(1) 当 第 一 个 执行 的 信息 不 足以 
分 析 某 些 特殊 情况 时 ，(2) 当 写 入 每 个 执行 的 信息 开销 过 大 时 (如 级 别 16) 。 仅 对 版 本 11.2.0.2 及 以 上 版 
本 有 效 
除了 表 3-1 描 述 的 级 别 外 ， 你 也 可 以 把 级 别 4 和 级 别 8 与 大 于 级 别 1 的 其 他 级 别 相 加 。 比 如 以 下 几 种 
情形 。 
级 别 12(4+8): 同时 应 用 级 别 4 和 级 别 8。 
级 别 28(4+8+16): 同时 应 用 级 别 4、 级 别 8 和 级 别 16。 
级 别 68(4+64): 同时 应 用 级 别 4 和 级 别 64。 
下 一 部 分 会 介绍 如 何 启用 和 禁用 SQL 跟踪 ， 如 何 配置 环 境 以 对 我 们 有 利 ， 以 及 如 何 找到 生成 的 跟 
踪 文 件 。 
调试 事件 是 由 数字 来 识别 的 ,是 用 来 在 一 个 运行 的 数据 库 引 擎 进程 中 设置 一 种 标志 的 方法 。 目 
的 是 改变 它 的 行为 ， 例 如， 启用 或 者 禁止 一 个 特性 ， 测 试 或 模拟 一 个 襄 误 或 事故 ,收集 跟 踪 或 者 调 
试 信息 。 一 些 调试 事件 不 是 简单 的 标志 ， 可 以 在 N 个 级 别 中 启用 。 每 个 级 别 都 有 自己 的 动作 。 在 一 
些 情况 下 ， 级别 是 一 个 块 或 者 内 存 结 构 的 地 址 
应 该 仅 在 Oracle Support 指 导 下 或 者 在 知道 调试 事件 会 导致 哪些 改变 的 情况 下 , 小 心 使 用 调试 事 
件 。 调 试 事件 启用 的 是 特定 码 路 径 。 因 此 ， 当 调试 事件 引起 问题 时 ， 应 该 在 不 使 用 调试 事件 的 情况 
下 确认 问题 是 否 能 重 现 。 
几乎 没有 调试 事件 会 被 Oracle 记 录 在 文档 里 。 如 果 有 文档 的 话 ， 通 常 可 以 在 Oracle Support 文 档 
中 找到 。 换 和 句 话 说 ， 调 试 事件 通常 不 会 记录 在 数据 库 引 擎 的 Oracle 官 方 文档 里 。 你 可 以 在 
$ORACLE_HOME/rdbms/mesg/oraus.msg 文 件 中 找到 完整 的 可 用 调试 事件 列表 。 请 注意 ， 此 文件 不 
是 存在 于 所 有 平台 的 版 本 中 。10 000 到 10 999 被 留 作 调 试 事件 。 
= 
1. 使 用 ALTER SESSION 启 用 SQL 跟 踪 
SOL Language Rejerence 手 册 中 记录 着 ALTER SESSION 语 句 ， 可 用 来 启用 SQL 跟 踪 。 请 看 下 例 : 
ALTER SESSION SET sql trace = TRUE 
你 仅 可 以 使 用 ALTER SESSION 语 句 将 sql_trace 设 置 为 TRUE， 这 相当 于 级 别 1。 在 实际 工作 中 , 级 别 1 
通常 是 不 够 的 。 在 大 多 数 情况 下 ， 你 需要 把 响应 时 间 彻 底 拆 开 ， 以 和 弄 清 楚 瓶 绒 到 底 在 哪里 。 基 于 这 个 


GD 或 者 安装 包含 修复 bug 8328200 的 补丁 包 ( 比如 11.2.0.1.0 Bundle Patch 7 for Exadata ) 


50 第 3 章 分 析 可 重 现 的 问题 


原因 ， 我 不 会 再 过 多 介绍 这 种 启用 SQL 跟踪 的 方法 。 我 要 介绍 的 是 Oracle Support 文 档 EVENT: 70046 
“enable SOL statement tracing (including binds/waits)”【〈 21154.1 ) 中 介绍 的 可 以 启用 任何 级 别 SQL 跟 踪 
的 方法 。 要 启用 和 禁用 任意 级 别 的 SQL 跟 踪 ， 需 要 执行 ALTER SESSION 语 句 来 设置 事件 的 初始 化 参数 。 
下 面 的 SQL 是 在 当前 会 话 启动 级 别 12 的 SQL 跟 踪 ， 请 注意 事件 编号 和 级 别 的 写法 。 

ALTER SESSION SET events '10046 trace name context forever, level 12" 

接 下 来 的 SQL 会 禁用 SQL 跟踪 ， 请 注意 这 里 不 是 通过 指定 为 级 别 0 来 禁用 。 

ALTER SESSION SET events “10046 trace name context off' 

你 也 可 以 使 用 ALTER SYSTEM 语 句 来 设置 事件 初始 化 参数 。 该 语句 的 语法 和 ALTER SESSION 是 一 样 的 。 
任何 情况 下 ， 在 系统 级 别 设置 SQL 跟 踪 都 是 没有 意义 的 ， 此 外 这 么 做 还 会 造成 庞大 的 开销 。 请 注意 ， 
这 只 对 启用 SQL 跟踪 后 的 会 话 有 效 。 


2. 使 用 DBMS_MONITOR 启 用 SQL 跟踪 

Oracle 数 据 库 也 提供 了 dbms _monitor 包 来 启用 和 禁用 SQL 跟踪 。 这 个 包 不 仅 提 供 了 一 种 启用 会 话 级 
别 的 扩展 SQL 跟踪 方法 ， 更 重要 的 是 ， 你 可 以 基于 会 话 属性 来 启用 和 禁用 SQL 跟踪 (参见 第 2 章 )。 这 
些 属 性 包括 : 客户 端 标识 符 、 服 务 名 、 模 块 名 和 动作 名 。 这 意味 着 如 果 应 用 配置 正确 ， 你 可 以 针对 执 
行 数 据 库 调用 的 会 话 单独 启用 和 禁用 SQL 跟踪 。 目 前 ， 这 是 特别 有 用 的 方法 ， 因 为 在 大 多 数 情 况 下 都 
会 用 到 连接 池 ， 所 以 用 户 已 经 不 会 关联 某 个 特定 的 会 话 。 

当 使 用 dbms_monitor 包 时 , 不 需要 直接 指定 诊断 事件 10046 的 级 别 ,每 个 过 程 提 供 三 个 参数 ( binds、 
waits 以 及 自 版 本 11.1 起 才 有 的 plan_stat ) 来 启用 SQL 跟踪 。 使 用 以 下 参数 可 以 启用 对 应 的 级 别 。 

口 启用 级 别 4，binds 需 要 设置 为 TRUE。 

口 启用 级 别 8，waits 需 要 设置 为 TRUE。 

口 启用 级 别 16，plan_stat 需 要 设置 为 a11 executions。 

口 启用 级 别 32，plan_stat 需 要 设置 为 never。 

口 dbms_monitor 无 法 启用 级 别 64。 

参数 waits 的 默认 值 为 TRUE。binds 的 默认 值 为 FALSE。plan_stat 的 默认 值 为 NULL ( 相当 于 
first_execution )。 因 此 ， 默 认 级 别 是 8。 

接 下 来 的 内 容 给 出 了 一 些 使 用 dbms_monitor 包 在 会 话 、 客 户 端 、 组 件 和 数据 库 级 别 启用 和 禁用 
SQL 跟踪 的 例子 。 请 注意 ， 在 默认 情况 下 ， 只 有 拥有 dba 和 角色 的 用 户 可 以 执行 dbms_monitor 包 下 的 
过 程 。 


@ 会 话 级 别 

为 会 话 启用 和 禁用 SQL 跟 踪 ，dbms_monitor 包 分 别提 供 了 session trace enable 和 session trace_ 
disable 过 程 。 

以 下 PL/SQL 调 用 针对 ID 为 127、 序 列 号 为 29 的 会 话 启 用 级 别 8 的 SQL 跟 踪 : 


dbms_ monitor.session trace enable(session id => 127， 
serial num => 29， 
waits => TRUE, 
binds => FALSE, 
plan stat => 'first execution') 
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所 有 参数 都 有 默认 值 。 如 果 有 两 个 关于 会 话 的 参数 没有 指定 , 就 针对 执行 此 PL/SQL 调 用 的 会 话 启 
用 SQL 跟踪 。 

当 通 过 session_trace_enable 启 用 SQL 跟踪 时 ， 也 会 相应 地 设置 视图 v$session 中 的 sql trace、 
sql_trace_waits 和 sql_trace_binds 列 。 此 外 ， 自 版 本 11.1 开 始 ，sql_trace_plan_stats 列 也 会 生效 。 
注意 ， 直 至 (并 包括 ) 10.2.0.5， 这 只 会 在 以 下 情况 下 发 生 : 在 执行 session_trace_enable 后 至 少 有 一 - 
条 SQL 语 句 在 被 跟踪 的 会 话 中 执行 。 例 如 ， 以 下 信息 在 执行 了 之 前 的 PL/SQL 调 用 后 才能 查询 到 : 

SQL> SELECT sql] trace, sql trace waits, sql trace binds, sql trace plan stats 

2 FROM v$session 


3 WHERE sid = 127; 
SQL_TRACE SQL TRACE WAITS SQL TRACE BINDS SQL TRACE PLAN STATS 


ENABLED TRUE FALSE FIRST EXEC 
下 面 的 PL/SQL 调 用 禁用 了 ID 为 127、 序 列 号 为 29 的 SQL 跟 踪 : 


dbms monitor.session trace disable(session id => 127, 
serial num => 29) 


请 注意 , 这 两 个 参数 都 有 上 默认 值 。 如 果 不 指定 , 会 禁用 与 执行 这 个 PL/SQL 调 用 对 应 的 会 话 的 SQL 
跟踪 。 

在 RAC ( Real Application Cluster， 真 实 应 应 用 程序 集 ) 环境 中 ，session trace enable 和 session_ 
trace_diable 需 要 在 存在 会 话 的 对 应 数据 库 实例 上 执行 。 


@ 客户 端 级 别 

为 客户 端 启 用 和 禁用 SQL 跟踪 ，dbms_monitor 包 分 别提 供 了 client id trace_enable 和 client id_ 
trace_disable 过 程 。 这 些 过 程 仅 会 在 已 设置 会 话 属性 的 客户 端 标识 符 的 情况 下 使 用 。 

以 下 PL/SQL 调 用 为 所 有 具有 指定 客户 端 标识 符 的 会 话 启 用 了 级 别 12 的 SQL 跟踪 : 


dbms_monitor.client id trace enable(client id => "helicon.antognini.ch '， 
waits => TRUE; 
binds => TRUE, 
plan stat => 'first execution') 


参数 client_id 没 有 默认 值 ， 并 且 区 分 大 小 写 。 

由 于 这 个 设置 会 保存 在 数据 字典 里 ， 所 以 实例 重启 后 也 会 存在 ， 同时， 在 一 个 RAC 的 环境 下 , 它 
对 所 有 数据 库 实 例 生效 。 

在 dba_enabled traces 和 12.1 多 租户 环境 下 的 cdb enabled traces 视 图 里 , 会 通过 client id trace enable 
过 程 ， 显 示 启 用 SQL 跟踪 的 用 户 标识 符 以 及 使 用 的 参数 。 例 如 , 使 用 以 上 的 PL/SQL 调 用 启用 SQL 跟踪 
后 ， 可 以 查 到 如 下 信息 : 


SQL> SELECT primary id AS client id, waits, binds, plan stats 
2 FROM dba enabled traces 
3 WHERE trace type = 'CLIENT ID'; 


CLIENT_ID WAITS BINDS PLAN_STAT9 


helicon.antognini.ch TRUE TRUE FIRST EXEC 
以 下 PL/SQL 调 用 针对 所 有 指定 客户 端 标 识 符 的 会 话 禁用 SQL 跟 踪 : 
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dbms_monitor.client id trace disable(client id => 'helicon.antognini.ch') 


过 程 client id trace disable 移 除 过 程 client id_trace enable 相 应 在 数据 字典 里 增加 的 信息 , 参 
数 client_ id 没有 默认 值 。 


@ 组 件 级 别 

包 dbms_monitor 分 别提 供 了 过 程 serv_mod act trace enable 和 serv_mod act trace _ disable 来 利用 
服务 名 、 模 块 名 和 动作 名 为 组 件 启用 和 禁用 SQL 跟踪 。 要 充分 使 用 这 些 过 程 ， 你 需要 设置 会 话 属性 、 
模块 名 和 动作 名 。 

以 下 PL/SQL 调 用 为 所 有 使 用 指定 参数 的 会 话 启 用 SQL 跟踪 : 

dbms_monitor.serv mod act trace enable(service name => “DBM11203.antognini.ch ， 


module name => 'mymodule', 
action name => 'myaction', 


waits => TRUE, 
binds => TRUE, 
instance name => NULL, 
plan _ stat => 'all executions') 


这 里 唯一 一 个 没有 默认 值 的 参数 是 第 一 个 service_name”。 参 数 module_name 和 action_name 默 认 值 
分 别 为 any module 和 any_action。 同 时 ，NULL 也 是 一 个 有 效 的 值 。 如 果 指 定 了 参数 action_name 的 值 ， 
那么 也 必须 指定 参数 module_name 的 值 。 如 果 不 设置 ， 则 会 引发 ORA-13859 错 误 。 在 RAC 环 境 下 ， 参 数 
instance_name 用 来 限定 具体 跟踪 哪个 数据 库 实例 。 默认 情 况 下 ，SQL 跟 踪 对 所 有 数据 库 实例 生效 。 请 
注意 ， 参 数 service_name 、module name 、action_name 和 instance_name 区 分 大 小 写 。 

由 于 设置 保存 在 数据 字典 中 ， 数 据 库 实例 重启 不 会 影响 使 用 。 

与 客户 端 级 别 的 SQL 跟踪 相同 ,在 dba_enabled traces 和 12.1 多 租户 环境 下 的 cdb_ enabled traces 
视图 里 ， 通 过 过 程 serv_mod_act_trace_enable， 会 显示 启用 了 SQL 跟踪 的 用 户 标识 符 组 件 以 及 使 用 的 
参数 。 使 用 以 上 PL/SQL 调 用 启用 SQL 跟踪 后 ， 你 可 以 查询 到 以 下 信息 ; 

SQL> SELECT primary id AS service name, qualifier id1 AS module name, 

2 qualifier id2 AS action name, waits, binds, plan stats 


3 FROM dba enabled traces 
4 WHERE trace type IN ('SERVICE', 'SERVICE MODULE', 'SERVICE MODULE ACTION'); 


SERVICE NAME MODULE NAME ACTION NAME WAITS BINDS PLAN _ STATS 


DBM10203.antognini.ch mymodule myaction TRUE TRUE ALL EXEC 


注意 ,根据 启用 SQL 跟踪 指定 的 参数 定义 ( 即 服务 名 、 模 块 名 和 动作 名 ), 会 将 列 trace_type 设 置 
成 SERVICE 、SERVICE_MODULE 或 者 SERVICE_MODLE_ACTION。 
以 下 PL/SQL 调 用 为 所 有 使 用 指定 参数 的 会 话 禁 用 SQL 跟踪 : 


dbms_monitor.serv mod act trace disable(service name => “DBM11203.antognini.ch ， 
module name => "mymodule ， 
action name => "myaction ， 
instance_name => NULL) 


中 服务 名 对 于 数据 库 来 说 是 一 个 逻辑 名 。 它 是 通过 初始 化 参数 service_names 或 包 dbms_service 进 行 配 置 的 。 一 -个 数 
据 库 可 以 有 多 个 服务 名 
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过 程 serv_mod_act trace_disable 会 移 除 过 程 serv_mod_act_trace_enable 添 加 到 数据 字典 里 的 信 
息 。 所 有 参数 都 与 过 程 serv_mod act _ trace_enable 具 有 一 样 的 默认 值 并 且 作 用 一 致 。 


@ 数据 库 级 别 

包 dbms _monitor 为 所 有 连接 到 数据 库 的 会 话 启 用 和 禁用 SQL 跟踪 ( 那些 后 台 进 程 创建 的 除外 ), 分 
别提 供 过 程 database_ trace_enable 和 database _ trace _ disable。 

以 下 PL/SQL 调 用 为 单个 数据 库 实 例 启 用 级 别 12 的 SQL 跟踪 : 


dbms_monitor.database trace enable(waits => TRUE, 
binds = TRUE; 
instance name => 'DBM11203', 
plan_stat => "first execution’) 


所 有 参数 都 有 默认 值 。 在 RAC 环 境 下 , 使 用 参数 instance_name 来 限制 要 跟踪 的 数据 库 实例 。 指 定 
的 值 可 以 从 视图 gv$instance 的 列 instance_name 获 得 。 如 果 将 参数 instance_name 设 置 为 NULL ( 同时 也 
是 默认 值 )，SQL 跟 踪 会 在 所 有 数据 库 实例 启用 。 请 注意 ， 参 数 instance_name 区 分 大 小 写 。 

由 于 设置 保存 在 数据 字典 中 ， 数 据 库 实例 重启 不 会 影响 使 用 。 

与 客户 端 级 别 和 组 件 级 别 的 SQL 跟踪 相同 ， 在 dba_enabled traces 和 12.1 多 租户 环境 下 的 
cdb_ enabled traces 视 图 里 ,会 通过 过 程 database_ trace _enable 显 示 启 用 SQL 跟踪 的 用 户 标 识 符 以 及 使 
用 的 参数 。 例 如 ， 使 用 以 上 PL/SQL 调 用 启用 SQL 跟踪 后 ， 可 以 查询 到 以 下 信息 : 


SQL> SELECT instance name, waits, binds, plan stats 
2 FROM dba enabled traces 
3 WHERE trace type = 'DATABASE'; 


INSTANCE NAME WAITS BINDS PLAN STATS 


DBM11203 TRUE TRUE FIRST EXEC 

以 下 PL/SQL 调 用 会 禁用 数据 库 级 别 的 SQL 跟 踪 , 同时 会 移 除 过 程 database_trace_enable 相 应 加 入 
到 数据 字典 里 的 信息 : 

dbms_monitor.database trace disable(instance name => 'DBM11203') 

请 注意 ， 这 不 会 禁用 其 他 级 别 (包括 会 话 级 别 、 客 户 端 级 别 或 组 件 级 别 ) 的 SQL 跟踪 。 如 果 将 参 
数 instance_name 设 置 为 NULL ( 同时 也 是 默认 值 )， 则 会 禁用 所 有 数据 库 实 例 的 SQL 跟踪 功能 。 


3. 使 用 DBMS SESSION 启用 SQL 跟踪 

之 前 曾 指出 ， 默 认 情 况 下 访问 包 dbms_monitor 是 有 限制 的 。 如 果 想 为 当前 连接 的 会 话 启用 或 禁用 
SQL 跟踪 ， 但 你 既 没 有 包 dbms_monitor 的 执行 权限 ， 又 不 想 执行 ALTER SESSION 语句 〈 比如 ， 因 为 语法 
很 难 记 )， 则 可 以 使 用 包 dbms session。 

包 dbms_session 包 含 两 个 过 程 : session trace_enable 和 session _ trace _ disable, 它们 的 功能 与 包 
dbms_monitor 下 的 同名 过 程 一 致 。 唯 一 的 区 别 就 是 ，dbms_session 下 的 过 程 只 能 为 当前 连接 的 会 话 启 
用 或 禁用 SQL 跟 踪 。 因 此 ， 拥 有 执行 ALTER SESSION 语句 权限 的 任何 用 户 都 可 以 使 用 这 两 个 过 程 。 

下 面 举例 说 明 如 何 使 用 dbms_session 启 用 和 禁用 SQL 跟踪 。 注 意 视 图 v$session 提 供 的 输出 表明 
SQL 跟踪 已 经 启用 : 


54 第 3 章 ”分 析 可 重 现 的 问题 


| SQL> BEGIN 

| 2 dbms_session.session trace enable(waits => TRUE, 

| 3 binds => TRUE, 
4 plan stat => 'all executions'); 
5 END; 
6 忒 


SQL> SELECT sql trace, sql trace waits, sql trace binds, sql trace plan stats 
2 FROM v$session 
3 WHERE sid = sys_ context('userenv','sid'); 


SQL_TRACE SQL TRACE WAITS SOL TRACE BINDS SQL TRACE PLAN STATS 


| ENABLED TRUE TRUE ALL EXEC 
SQL> BEGIN 
2 dbms_session.session trace disable; 
3 END; 
4 7 


4. 触发 SQL 跟踪 

在 上 面 的 内 容 中 ， 你 看 到 了 启用 和 禁用 SQL 跟踪 的 不 同方 法 。 最 简单 的 情况 是 手工 执行 SQL 语句 
或 PL/SQL 调 用 。 不 过 ， 有 时 自动 触发 SQL 跟踪 很 必要 。 “自动 ”在 这 里 表示 代码 必须 加 在 某 处 。 

最 简单 的 方法 是 在 数据 库 级 别 创建 一 个 登录 触发 器 。 为 了 避免 启用 所 有 用 户 的 SQL 跟踪 ， 我 通常 
建议 创建 一 个 角色 ( 在 接 下 来 的 例子 中 命名 为 sql_trace )， 并 暂时 只 把 它 赋 予 给 需要 启用 SQL 跟踪 的 
用 户 。 以 下 示例 是 脚本 sql trace trigger.sql 的 节选 : 

CREATE ROLE sql trace; 

CREATE OR REPLACE TRIGGER enable sql _ trace AFTER LOGON ON DATABASE 

BEGIN 

IF (dbms_session.is role enabled('SQL TRACE')) 

THEN 
EXECUTE IMMEDIATE “ALTER SESSION SET timed statistics = TRUE'; 
EXECUTE IMMEDIATE “ALTER SESSION SET max dump file size = Unlimited ; 
dbms_session.session trace enable; 

END IF; 

END; 

自然 地 ， 这 也 可 以 定义 成 针对 单个 架构 的 触发 器 或 者 基于 其 他 执行 的 检查 ， 例 如 ， 基 于 userenv 
命令 。 请 注意 ， 除 了 启用 SQL 跟踪 之 外 ， 还 可 以 做 一 些 与 SQL 跟踪 相关 的 初始 参数 设置 的 练习 ( 更 多 
内 容 会 在 本 章 后 续 部 分 介绍 )。 


注意 执行 上 面 的 触发 器 所 需要 的 ALTER SESSION 执行 权限 不 能 通过 角色 赋予 ， 而 是 需要 直接 赋予 给 
用 户 来 创建 此 触发 器 。 


另 一 个 方法 是 在 应 用 里 直接 添加 代码 来 启用 SQL 跟踪 。 某 些 用 来 触发 代码 的 参数 也 需要 添加 进 
| 去 。 胖 客户 端 应 用 的 命令 行 参数 或 者 网 页 应 用 的 附加 HTTP 参 数 就 是 一 个 很 好 的 例子 。 
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5. 跟踪 文件 里 的 定时 信息 

初始 化 参数 timed_statistics 控 制 着 跟踪 文件 里 的 定时 信息 ， 比 如 运行 时 间 和 CPU 时 间 ， 此 参数 
可 以 设置 成 TRUE 或 FALSE。 如 果 设 置 成 TRUE， 定 时 信息 会 保存 到 跟踪 文件 里 。 如 果 设 置 成 FALSE， 则 相 
反 。 然 而 ,根据 工作 平台 的 不 同 ， 部 分 平台 下 也 会 记录 定时 信息 。timed_statistics 的 默认 值 取 决 于 
另外 一 个 初始 化 参数 : statistics_ level。 如 果 将 statistics_ level 设 置 成 pasic, 那么 timed statistics 
默认 为 FALSE。 否 则 ，timed_statistics 默 认为 TRUE。 

通常 来 说 ， 如 果 定 时 信息 不 可 用 ,那么 跟踪 文件 是 没 用 的 。 因 此 ,在 启用 SQL 跟踪 前 ， 请 确保 参 
数 timed statistics 已 设置 为 TAUE。 比 如， 可 以 执行 以 下 SQL 语句 : 

ALTER SESSION SET timed statistics = TRUE 


动态 初始 化 参数 
初始 化 参数 有 静态 的 ， 也 有 动态 的 。 如 果 是 动态 参数 ,代表 可 以 改变 它们 而 不 用 重启 实例 。 在 动 
态 初始 化 参数 中 ， 有 些 参 数 仅 可 以 在 会 话 级 别 做 更 改 , 有 些 只 可 以 在 系统 级 别 修 改 , 其 他 参数 两 者 均 
可 。 在 会 话 和 系统 级 别 修改 初始 化 套数 ， 可 以 分 别 使 用 ALTER SESSION 和 ALTER SYSTEM 语 句 。 系 统 级 别 
的 初始 化 参数 修改 完 会 立刻 生效 或 者 仅 对 修改 后 创建 的 会 话 生 效 。v$parameter 视 图 中 , 或 者 更 准确 地 
说 是 列 isses modifiable 和 issys modifiable 中 , 纪录 着 初始 化 参数 在 哪些 情况 下 可 以 进行 修改 。 


6. 限制 跟踪 文件 大 小 

通常 , 没有 人 会 在 意 跟 踪 文 件 的 大 小 限制 。 如 果 必 须要 限制 其 大 小 ， 可 以 在 会 话 或 者 系统 级 别 设 
置 初始 化 参数 max_dump_ 人 ile_ size。 指定 具体 数值 后 跟 K 或 者 M， 代表 KB 或 者 MB， 以 此 表示 跟踪 文件 
的 最 大 文件 大 小 。 如 果 和 希望 没有 限制 ， 可 以 像 以 下 SQL 这 样 ， 设 置 初始 化 参数 的 值 为 unlimited: 

ALTER SESSION SET max dump file size = “unlimited 

从 版 本 11.1 开 始 ， 当 达到 限制 时 ， 会 在 告警 日 志 里 记录 如 下 信息 : 


Non critical error ORA-48913 caught while writing to trace file "/uo0/app/oracle/diag/rdbms/ 
dbm11203/DBM11203/trace/DBM11203_ora 6777.trc" 

Error message: ORA-48913: Writing into trace file failed, file size limit [512000] reached 
Writing to the above trace file is disabled for now on... 


7. 找到 跟踪 文件 

跟踪 文件 是 由 在 数据 库 服 务 器 上 运行 的 数据 库 引 擎 服务 器 进程 创建 的 。 这 表明 跟踪 文件 是 由 数据 
库 服 务 器 直接 写 入 到 硬盘 。 在 版 本 10.2 中 ,不同 进程 产生 的 跟踪 文件 会 写 人 不 同 的 目录 。 

口 专用 服务 器 进程 创建 的 跟踪 文件 会 写 人 初始 化 参数 user dump_dest 指 定 的 位 置 。 

口 后 台 进 程 创建 的 跟踪 文件 会 写 人 初始 化 参数 background_dump_dest 指 定 的 位 置 。 

进程 类 型 可 以 通过 视图 v$session 下 的 type 字 段 来 辨别 。 但 奇怪 的 是 , 并 不 是 所 有 后 台 进 程 都 可 以 
在 视图 v$bgprocess 中 查 到 。 

从 版 本 11.1 开 始 , 随 着 自动 诊断 信息 库 ( ADR ) 的 引入 ,初始 化 参数 user_dump_dest 和 background_ 
dump_dest 已 被 初始 化 参数 diagnostic_dest 所 取代 。 由 于 新 的 初始 化 参数 只 设置 了 基础 目录 ， 因 此 你 
可 以 查询 视图 v$diag_info 来 获取 跟踪 文件 的 准确 位 置 。 以 下 查询 列举 出 了 初始 化 参数 与 跟踪 位 置 的 
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区 别 : 


SQL> SELECT value FROM v$parameter WHERE name = "diagnostic dest'; 


/uo0/app/oracle 


SQL> SELECT value FROM v$diag info WHERE name = 'Diag Trace'; 


/uo00/app/oracle/diag/rdbms/dbm11203/DBM11203/trace 
请 注意 , 在 12.1 多 租户 环境 中 , 不 能 在 PDB 级 别 设 置 初始 化 参数 user dump_dest .background dump_ 
dest 和 diagnostic dest。 
跟踪 文件 以 前 曾 根据 版 本 和 平台 来 命名 。 在 最 近 的 版 本 中 ， 命 名 是 根据 以 下 结构 : 
{instance name} {process name} {process id}.trc 
下 面 是 该 结构 的 分 解说 明 。 
口 instance_name: 这 是 初始 化 参数 instance_name 的 值 。 请 注意 ， 尤 其 在 RAC 环 境 中 ， 初 始 化 参 
数 instance_name 与 初始 化 参数 db name 是 不 同 的 。 初 始 化 参数 instance_name 可 以 在 视图 
gv$instance 的 列 instance_name 中 查 到 。 
口 process_name: 这 是 产生 跟踪 文件 的 进程 的 小 写 名 称 。 对 于 专用 服务 器 进程 ， 会 用 ora 作 为 进 
程 名 。 对 于 共享 服务 器 进程 ， 进 程 名 来 自视 图 v$dispatcher 或 vgshared _server 的 name 列 。 对 于 
并 行 从 属 进程 , 进程 名 根据 视图 v$px_process 的 server_name 列 来 命名 。 对 于 其 他 大 部 分 后 台 进 
程 ， 进 程 名 根据 视图 v$bgprocess 的 name 列 来 命名 。 
口 process id: 系统 级 别 的 进程 标识 符 ( Windows 下 是 线程 标识 符 ), 这 个 值 可 以 在 视图 v$process 
的 spid 列 中 找到 。 
根据 这 里 提供 的 信息 , 我 们 可 以 写 出 一 个 类 似 脚本 map_session_to_tracefile.sql 中 的 语句 。 但 这 
样 的 语句 只 能 在 10.2 版 本 中 使 用 。 从 11.1 版 本 开始 , 就 像 下 面 给 出 的 例子 , 只 需要 查询 视图 v$diag_info 
或 者 v$process 就 可 以 : 
SQL> SELECT value 


2 FROM v$diag info 
3 WHERE name = 'Default Trace File'; 


/uo0/app/oracle/diag/rdbms/dba111/DBA111/trace/DBA111 ora 23731.trc 


SQL> SELECT p.tracefile 
2 FROM v$process p, v$session s 
3 WHERE p.addr = s.paddr 
4 AND s.sid = sys_context('userenv','sid'); 


TRACEFILE 


/u00/app/Voracjle/diag/rdbms/dbal11/DBA111VtTace/DBA111 ora 23731.trc 
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注意 ， 视 图 V$diag_info 只 为 当前 对 话 提供 信息 。 


跟踪 文件 会 包含 机 密 信 息 吗 
默认 情况 下 ,不 是 任何 用 户 都 可 以 访问 跟踪 文件 ,这样 做 的 好 处 是 因为 跟踪 文件 里 可 能 包含 机 
密 信 息 。 实 际 上 ， 包 含 文字 的 SQL 语句 和 绑 定 变量 的 值 都 会 被 记录 在 跟踪 文件 里 。 这 表明 任何 存储 
在 数据 库 里 的 数据 也 都 可 以 被 写 入 跟踪 文件 
例如 ， 在 Unix/Linux 数 据 库 服务 器 上 ， 跟 踪 文件 属于 运行 数据 库 引 擎 二 进 制 文件 的 用 户 和 组 ， 
并 且 默 认 情况 下 它 拥有 0640 权 限 。 换 名 话说， 只 有 与 运行 数据 库 引 擎 的 用 户 处 于 同一 组 中 的 用 户 才 
可 以 读 取 跟 踪 文 件 
因此 ， 如 果 那 些 能 够 访问 数据 库 的 用 户 需要 执行 任务 ， 就 没有 什么 理由 阻止 他 们 去 访问 跟踪 
文件 。 实 际 上 ， 从 安全 的 角度 看 ， 跟 踪 文 件 仅 对 于 那些 无 权 访问 数据 库 的 用 户 来 说 才 是 有 用 的 信 
息 源 。 为 此 ， 数 据 库 引擎 提供 了 一 个 未 公开 的 初始 化 参数 trace files _public。 默 认 情 况 下 ， 它 
被 设置 为 FALSE。 如 果 设置 成 TRUE， 那 么 跟踪 文件 会 对 所 有 具有 访问 数据 库 权 限 的 用 户 公开 。 此 初 
始 化 参数 不 是 动态 的 ， 因 此 ， 修 改 需要 重启 实例 。 请 注意 ， 在 12.1 多 租户 环境 下 ， 不 可 以 在 PDB 
级 别 设置 此 参数 
比如 ， 在 Unix/Linux 下 ， 把 trace 人 les public 设 置 为 TRUE， 那 么 默认 的 权限 会 变 为 0644。 这 
样 ， 所 有 能 访问 数据 库 的 用 户 都 可 以 访问 跟踪 文件 。 
从 安全 的 角度 看 , 只 有 当 访问 数据 库 不 受 限 时 , 把 初始 化 参数 trace files_public 设 置 成 TRUE 
才 会 成 为 问题 。 为 了 方便 访问 跟踪 文件 ， 常 见 的 做 法 是 通过 SMB 或 NFS 共 享 目录 ， 或 者 通过 HTTP 
接口 来 实现 。 无论 如 何 ， 每 次 需要 跟踪 文件 时 都 让 DBA 手 工 传 一 份 ， 这 样 可 以 最 大 程度 地 避免 很 
多 问题 
9 
使 用 初始 化 参数 tracefile_identifier 也 可 能 轻松 找到 想 要 的 跟踪 文件 。 实 际 上 ， 使 用 这 个 初始 
化 参数 可 以 为 跟踪 文件 的 命名 增加 最 多 255 个 字符 的 自 定义 标识 。 添 加 标识 的 跟踪 文件 名 结构 会 变 成 
以 下 这 样 : 
{instance name} {process name} {process id} {tracefile identifier}.trc 
初始 化 参数 tracefile identifier 只 可 以 在 会 话 级 别 设置 ， 并且 只 能 是 专用 服务 器 进程 。 需 要 注 
意 的 是 ， 每 当 一 个 会 话 动态 修改 了 该 参数 ， 都 会 自动 创建 一 个 新 的 跟踪 文件 。 可 以 在 视图 v$process 
的 列 traceid 中 找到 初始 化 参数 tracefile identifier 的 值 。 请 注意 ， 在 10.2 版 本 中 ， 该 参数 只 对 同样 
的 会 话 生 效 ， 其 他 会 话 看 到 的 参数 值 都 是 NULL。 
现在 我 们 知道 了 什么 是 SQL 跟踪 ,如 何 配置 、 启 用 和 禁用 它 , 以 及 在 哪里 能 找到 生成 的 跟踪 文件 。 
下 面 来 讨论 一 下 它 的 结构 和 用 来 分 析 的 工具 ， 以 及 因此 能 看 到 的 跟踪 文件 的 内 容 。 


3.1.2 ”跟踪 文件 的 结构 


跟踪 文件 包含 特定 进程 执行 数据 库 调 用 的 信息 ,实际 上 , 当 一 个 进程 ID 在 操作 系统 级 别 被 重用 时 ， 
会 导致 一 个 跟踪 文件 里 包含 多 个 进程 信息 。 因 为 不 同 的 会 话 可 能 会 使 用 同一 个 进程 (比如 共享 服务 器 
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或 者 并 行 从 属 进程 ) 并 且 每 个 会 话 都 有 不 同 的 会 话 属 性 〈 比如 模块 名 和 动作 名 )， 所 以 跟踪 文件 会 被 
分 成 多 个 逻辑 部 分 。 请 看 图 3-3 的 例子 (这 两 个 跟踪 文件 和 本 章 的 其 他 文件 都 可 供 下 载 )。 


DBM11203_s000_24437 trc DBM11203_ora_7978.trc 
| “~ CLIENT IDi(helicon antogninich) 
es | MODULE NAME:(Module 1) 
EE a 
一 心 ACTION NAMEAction 12) | 


“** SESSION ID:(35.5) | 


soy | 


”ACTION NAME:(Action 13) 


Ne 


”SESSION ID:(37.7) 


MODULE NAME:(Module 2) 


[*** SESSION ID:(36.27) 


| SESSION ID:(37.7) 
| 


| 


图 3-3 ”跟踪 文件 可 以 由 多 个 逻辑 段落 组 成 。 左边 是 一 个 共享 服务 器 的 跟踪 文件 , 包含 三 个 会 话 信 
息 。 右 边 是 专用 服务 器 的 跟踪 文件 ， 包 含 一 个 客户 端的 两 个 模块 和 五 个 动作 信息 


在 图 3-3 右 边 显示 的 跟踪 文件 结构 可 以 使 用 之 前 提供 的 PL/SQL 块 来 开启 SQL 跟 踪 : 


DECLARE 
1 dummy VARCHAR2(10); 
BEGIN 
dbms_session.set identifier(client id => "helicon.antognini.ch'); 
dbms application info.set module(module name => 'Module 1 ， 
action name => 'Action 11'); 
-- Code module 1, action 11 
SELECT 'Action 11' INTO 1 dummy FROM dual; 
dbms_application info.set module(module name => 'Module 1 ， 
action name => 'Action 12 ); 
-- Code module 1, action 12 
SELECT ‘Action 12' INTO 1 dummy FROM dual; 
dbms application info.set module(module name => 'Module 1', 
action name => 'Action 13'); 
-- Code module 1, action 13 
SELECT 'Action 13' INTO 1] dummy FROM dual; 
dbms application info.set module(module name => 'Module 2', 
action name => 'Action 21'); 
-- Code module 2, action 21 
SELECT "Action 21' INTO 1 dummy FROM dual; 
dbms application info.set module(module name => 'Module 2 ， 
action name => 'Action 22'); 
-- Code module 2, action 22 
SELECT ‘Action 22” INTO 1 dummy FROM dual; 
END; 
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在 图 3-3 中 ， 在 跟踪 文件 里 由 三 个 星 号 ( *** ) 开头 的 标签 用 来 标识 段落 。 跟 踪 文 件 之 间 的 区 别 不 
光 是 数据 库 引擎 会 在 每 个 部 分 重复 记录 一 些 信息 , 另外 还 会 加 上 时 间 戳 。 下 面 是 由 PL/SQL 块 生成 的 跟 


踪 文件 的 片段 内 容 : 


*** CLIENT ID: (helicon.antognini.ch) 2012-11-30 10:05:05.531 


*** MODULE NAME:(Module 
*** ACTION NAME: (Action 


***¥ MODULE NAME: (Module 
*** ACTION NAME:(Action 


*** MODULE NAME:(Module 
*** ACTION NAME:(Action 


*** MODULE NAME: (Module 
*** ACTION NAME: (Action 


*** MODULE NAME:(Module 
*** ACTION NAME:(Action 


1) -2012-11-30 10:05:05.531 
11) 2012-11-30 10:05:05.531 


1) 2012-11-30 10:05:05.532 
12) 2012-11-30 10:05:05.532 


1) 2012-11-30 10:05:05.533 
13) 2012-11-30 10:05:05.533 


2) 2012-11-30 10:05:05.533 
21) 2012-11-30 10:05:05.533 


2) 2012-11-30 10:05:05.534 
22) 2012-11-30 10:05#05.534 


这 些 逻 辑 会 话 标签 很 有 用。 有 了 它们 ， 才 可 以 根据 你 的 需要 来 提取 相关 信息 。 例 如 ， 如 果 你 关注 
的 性 能 问题 与 一 个 特殊 动作 有 关 , 就 可 以 把 跟踪 文件 里 相关 的 部 分 独立 出 来 。 可 以 使 用 工具 TRCSESS 
来 实现 ， 下 面 我 们 来 介绍 一 下 。 


3.1.3 使 用 TRCSESS 


可 以 根据 之 前 介绍 的 逻辑 部 分 来 使 用 命令 行 工具 TRCSESS, 从 一 个 或 者 多 个 跟踪 文件 中 提取 需要 
的 信息 。 如 果 运 行 TRCSESS 时 未 指定 任何 参数 作为 输入 ,那么 返回 的 就 是 完整 的 TRCSESS 参 数列 表 ， 


其 中 包括 简短 的 描述 


trcsess [output=<output 


file name >] [session=<session ID>] [clientid=<clientid>] 


[service=<service name>] [action=<action name>] [module=<module name>] 
<trace file names> 


output=<output file name> output destination default being standard output. 
session=<session Id> session to be traced. 

Session id is a combination of session Index & session serial number e.g. 8.13. 
clientid=<clientid> clientid to be traced. 

service=<service name> service to be traced. 

action=<action name> action to be traced. 

module=<module name> module to be traced. 

<trace file names> Space separated list of trace files with wild card '*' supported. 


正如 你 所 见 ， 可 以 将 会 话 、 客 户 端 标识 符 、 服 务 名 称 、 模 块 名 称 和 动作 名 称 指定 为 参数 。 例 如 ， 
要 从 跟踪 文件 DBM11203_ora_7978.trc 中 提取 关于 Action 12 的 信息 ， 并 写 入 到 一 个 名 为 action12.trc 的 
新 文件 中 ， 可 以 使 用 下 面 的 命令 : 


trcsess output=action12.trc action="Action 12" DBM11203_ora 7978.trc 
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请 注意 ， 参 数 clientid、service 、action 和 module 都 是 区 分 大 小 写 的 。 


3.1.4 ”探查 器 


一 旦 你 定位 到 正确 的 跟踪 文件 ,或 者 使 用 TRCSESS 提 取出 了 需要 的 部 分 ,就 开始 着 手 分 析 内 容 吧 。 
你 需要 使 用 探查 器 ( profiler ), 目的 是 基于 原始 跟踪 文件 的 内 容 生 成 一 份 格式 化 输出 。Oracle 的 服务 端 
和 客户 端 都 包含 此 工具 ， 叫 作 TKPROF ( Trace Kemel PROFiler )。 即 使 工具 输出 的 结果 对 有 些 状况 有 
帮助 ， 有 时 也 并 不 足以 胜任 快速 定位 性 能 问题 的 工作 。 奇 怪 的 是 ，Oracle 低 估 了 此 工具 的 重要 性 ， 从 
Oracle7 开 始 引 入 此 工具 后 就 很 少 改 进 它 。 现 在 市 面 上 有 一 些 商业 的 和 免费 的 探查 器 。 我 自己 也 开发 了 
一 个 免费 的 探查 器 TVDS$XTAT。 你 也 可 以 考虑 使 用 其 他 的 探查 器 :OraSRP Method R Profiler 和 Method 
R Tools suite”。 甚 至 Oracle 都 建议 ( 通过 Oracle 支 持 ) 使 用 另 一 个 称 为 Trace Analyzer 的 探查 器 。 

接 下 来 的 两 节 会 介绍 其 中 的 两 个 探查 器 。 首 先是 TKPROF ， 尽 管 它 有 很 多 不 足 ， 却 是 唯一 一 个 在 
任何 情况 下 都 能 使 用 的 探查 器 。 实 际 上 ， 很 多 时 候 你 不 能 在 数据 库 服务 器 上 安装 其 他 探查 器 或 者 把 跟 
踪 文 件 下 载 到 其 他 机 器 上 。 在 这 样 的 情况 下 ，TKPROF 是 很 有 用 的 。 然 后 我 会 介绍 自己 写 的 探查 器 。 
这 里 会 用 到 使 用 以 下 PL/SQL 块 生成 的 跟踪 文件 : 

DECLARE 

1 count INTEGER; 
BEGIN 
FOR ¢ IN (SELECT extract(YEAR FROM d), id, pad 
FROM +t 
ORDER BY extract(YEAR FROM d), id) 
LOOP 
NULL; 
END LOOP; 
FOR i IN 1..10 
LOOP 
SELECT count(n) INTO 1 count 
FROM 七 
WHERE id < i*123; 
END LOOP; 
END ; 


3.1.5 ”使 用 TKPROF 


TKPROF 是 命令 行 工 具 ， 它 的 主要 作用 是 输入 一 个 原始 的 跟踪 文件 并 输出 一 个 格式 化 后 的 文本 文 
件 。 此 工具 还 可 以 生成 SQL 脚本 以 在 数据 库 中 加 载 数据 ， 尽 管 这 个 特性 很 少 有 人 使 用 。 

仅 通过 指定 一 个 输入 文件 和 输出 文件 可 以 执行 最 简单 的 分 析 。 在 下 面 的 例子 中 ， 输 入 文件 是 
DBM11106_ora_6334.trc， 输 出 文件 是 DBM11106_ora_6334.trc。 

tkprof DBM11106 ora 6334.trc DBM11106 ora 6334.txt 


中 具体 信息 请 访问 http://www.oracledba.ru/orasrp。 

@) 具体 信息 请 访问 http://method-rcom。 

@ 更 多 信息 请 查看 Oracle Support 文 档 TRCANLZR (7TRC4): SOL _TRACE/Event 10046 Trace File Analyzer-Tool for 
Interpreting Raw SOLTraces ( 224270.1 ) 
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尽管 默认 的 输出 文件 扩展 名 是 prf， 我 个 人 还 是 喜欢 使 用 txt。 在 我 看 来 ， 使 用 扩展 名 可 以 让 所 有 
人 明白 文件 类 型 ， 同 时 可 以 在 任何 操作 系统 中 正确 识别 出 来 。 

未 附加 其 他 参数 的 分 析 仅 对 非常 小 的 跟踪 文件 有 用 。 在 大 多 数 情况 下 ， 你 需要 指定 多 个 参数 来 获 
得 一 个 更 好 的 输出 文件 。 


1. TKPROF 参 数 
如 果 运 行 TKPROF 时 未 附加 参数 ， 返 回 的 就 是 完整 的 TRCSESS 参 数列 表 ， 其 中 包含 简短 的 描述 。 


Usage: tkprof tracefile outputfile [explain= ] [table= ] 

[print= ] [insert= ] [sys= ] [sort= ] 
table=schema.tablename Use 'schema.tablename' with “explain=” option. 
explain=user/password Connect to ORACLE and issue EXPLAIN PLAN. 
print=integer List only the first 'integer' SQL statements. 
aggregate=yes |no 
insert=filename List SOL statements and data inside INSERT statements. 


SyS=no TKPROF does not list SQL statements run as user SY9， 
record=filename Record non-recursive statements found in the trace file. 
waits=yes|no Record summary for any wait events found in the trace file. 
sort=option Set of zero or more of the following sort options: 


prscnt number of times parse was called 
prscpu cpu time parsing 

prsela elapsed time parsing 

prsdsk number of disk reads during parse 
prsqry number of buffers for consistent read during parse 
prscu number of buffers for current read during parse 
prsmis number of misses in library cache during parse 
execnt number of execute was called 

execpu cpu time spent executing 

exeela elapsed time executing 

exedsk number of disk reads during execute 

exeqry number of buffers for consistent read during execute 
execu number of buffers for current read during execute 
exerow number of rows processed during execute 

exemis number of library cache misses during execute 
fchcnt number of times fetch was called 

fchcpu cpu time spent fetching 

fchela elapsed time fetching 

fchdsk number of disk reads during fetch 

fchqry number of buffers for consistent read during fetch 
fchcu number of buffers for current read during fetch 
fchrow number of rows fetched 

userid userid of user that parsed the cursor 


每 个 参数 的 功能 如 下 。 

口 explain 会 使 TKPROF 为 跟踪 文件 中 的 每 个 SQL 语 句 生 成 执行 计划 ,实现 方式 是 通过 执行 EXPLAIN 
PLAN 语句 产生 的 结果 (关于 此 SQL 语句 的 详细 信息 请 看 第 10 章 )。 很 显然 ， 为 了 执行 SQL 语句 ， 
就 必须 连接 数据 库 。 因 此 ， 此 参数 用 来 指定 用 户 名 、 密 码 和 连接 字符 串 。 可 供 使 用 的 格式 是 
explain=user/password@connect string 和 explain=user/password。 请 注意 ， 为 了 能 够 尽 最 大 可 
能 得 到 正确 的 执行 计划 ， 你 应 该 使 用 与 生成 跟踪 文件 时 相同 的 用 户 ， 并 且 确 保 所 有 查询 优化 器 
的 初始 化 参数 也 与 生成 跟踪 文件 时 相同 。 同 时 也 要 注意 初始 化 参数 会 随 着 程序 运行 时 或 登录 触 
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发 右 而 更 改 。 最 好 的 情况 就 是 你 能 使 用 相同 的 用 户 ， 但 无 论 如 何 ， 即 使 所 有 条 件 都 满足 ， 因 为 
使 用 EXPLAIN PLAN 语 句 生 成 的 执行 计划 不 一 定 与 真正 的 执行 计划 一 致 ( 原因 会 在 第 10 章 解释 )， 
所 以 不 建议 指定 explain 参 数 。 如 果 指 定 了 错误 的 用 户 名 、 密 码 或 连接 字符 串 , 则 会 分 析 跟 踪 文 
件 而 不 返回 任何 错误 信息 。 反 之 ， 则 会 在 输出 文件 的 头 部 找到 类 似 以 下 的 错误 信息 : 

error connecting to database using: scott/lion 


ORA-01017: invalid username/password; logon denied 
EXPLAIN PLAN option disabled. 


口 table 只 可 以 和 explain 参 数 一 起 使 用 。 它 的 作用 实际 上 是 指定 哪 张 表 使 用 EXPLAIN PLAN 语句 生 
成 执行 计划 。 通 常 可 以 不 指定 此 参数 ， 因 为 TKPROF 会 自动 创建 并 删除 一 个 名 为 
prof$plan_table 的 计划 表 用 做 分 析 , 总之, 如果 用 户 无 法 创建 表 ( 比如 没有 CREATE TABLE 权 限 )， 

就 必须 指定 table 参 数 。 例 如 ， 要 指定 system 用 户 下 的 表 plan _ table， 那 么 参数 必须 设置 成 

table=system.plan_table。 执行 分 析 的 用 户 必须 对 特定 的 表 具 有 SELECT 、INSERT 和 DELETE 权 限 。 

同样 ， 错 误 也 只 会 记录 在 输出 文件 里 。 

print 用 来 限制 输出 文件 里 SQL 语句 的 行 数 。 默 认 情 况 下 没有 限制 。 这 个 参数 只 有 与 参数 sort 

一 起 使 用 才 有 意义 ， 用 来 输出 top SQL 语句 。 例 如 ， 为 了 只 获得 10 条 SQL 语句 ， 参 数 必 须 设置 

成 print = 10。 

口 aggregate 指 定 TKPROF 该 如 何 处 理 相 同 的 SQL 语句 。 默 认 情 况 下 (aggregate=yes )， 所 有 指定 
SQL 语句 的 信息 都 会 进行 汇总 。11.2 版 本 中 又 进一步 要 求 执行 计划 也 要 相同 才 可 以 。 因 此 , 在 
11.2 版 本 中 ,默认 会 汇总 对 应 SQL 语句 的 每 条 执行 计划 信息 。 汇 总 信息 会 独立 于 跟踪 文件 里 的 
SQL 语句 ， 因 此 就 汇总 来 说 ， 信 息 会 缺少 一 部 分 。 即 使 在 许多 情况 下 默认 设置 可 以 满足 分 析 ， 
但 有 时 最 好 设置 aggregate=no 来 检查 单独 的 SQL 语句 。 

口 TKPROF 使 用 参数 insert 生 成 可 以 存储 进 数 据 库 的 SQL 脚本 。 脚 本 名 直接 用 参数 自身 指定 ， 比 
如 insert = load.sql。 

口 sys 人 参数 指 定 由 sys 用 户 执行 的 SQL 语句 ( 典型 情况 下 ， 解 析 操 作 需 要 递归 查询 数据 字典 ) 是 否 
要 写 人 输出 文件 。 默 认 值 是 yes， 但 大 多 数 时候 我 更 愿意 设置 成 no 来 避免 无 用 的 信息 写 和 人 输出 
文件 。 你 通常 无 法 控制 sys 用 户 递归 执行 SQL 语句 ， 因 此 这 是 多 余 的 。 

口 TKPROF 使 用 参数 record 生 成 跟踪 文件 里 所 有 非 递 归 语 句 的 SQL 脚本 。 脚 本 名 称 直接 由 参数 指 
定 ( 例如，record = replay.sql )。 根 据 文档 ， 这 个 特性 可 以 用 来 手工 重播 SQL 语句 ， 但 由 于 
不 会 处 理 绑 定 变量 ， 这 通常 无 法 实现 。 

口 waits 确 定 是 否 将 等 待 事件 信息 加 入 输出 文件 。 默认 情况 下 是 加 入 的 。 就 个 人 而 言 ， 输 出 文件 
里 的 等 待 事件 非常 重要 ， 我 认为 不 应 该 指定 waits = no。 

口 sort 指 定 写 入 输出 文件 的 SQL 语句 顺序 。 默 认 情 况 下 ,是 根据 在 跟踪 文件 里 的 读 取 顺 序 排序 的 。 
基本 上 ， 你 可 以 根据 资源 利用 ( 比如 调用 数 、CPU 时 间 和 物理 读 ) 或 响应 时 间 ( 即 运行 时 间 ) 
来 对 输出 进行 排序 。 如 你 所 见 ， 对 于 大 多 数 选项 〈 比如 运行 时 间 )， 每 种 类 型 的 数据 库 调 用 的 
值 都 可 用 来 排序 : 比如 ， 解 析 游 标 所 花费 的 时 间 prsela， 执 行 游标 所 花费 的 时 间 exeela， 以 及 
从 一 个 游标 里 获取 数据 所 花费 的 时 间 fchela。 尽管 你 可 以 根据 多 种 选择 和 组 合 来 进行 排序 , 但 
对 研究 性 能 问题 来 说 只 有 一 种 排序 是 真正 有 用 的 : response time。 因 此 ， 你 应 该 指定 sort = 
prsela,exeela,fchela。TKPROF 支 持 在 参数 中 传人 多 个 值 ， 只 需要 用 逗号 分 隔 即 可 ， 甚 至 可 


口 
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以 传人 不 同 单位 的 值 。 请 注意 ， 当 跟踪 文件 里 包含 多 个 会 话 并 且 指定 了 参数 aggregate=no， 就 
会 分 别 对 每 个 会 话 的 SQL 语句 进行 排序 。 

基于 以 上 信息 ,我 个 人 常用 的 TKPROF 参 数 如 下 : 

tkprof {input trace file} {output file} sys=no sort=prsela,exeela,fchela 


现在 你 知道 如 何 使 用 TKPROF 了 ， 让 我 们 来 看 看 它 生 成 的 输出 文件 。 


2. 解释 TKPROF 输 出 
分 析 的 输出 文件 根据 以 下 参数 生成 : 


tkprof DBM11203 ora_28030.tTrC DBM11203 ora 28030.txt 
sort=prsela,exeela, fchela print=4 explain=chris/ian aggregate=no 


请 注意 ， 这 里 不 是 建议 你 根据 以 上 参数 这 么 做 ， 只 是 为 了 向 你 展示 一 个 详细 的 输出 。 跟 踪 文 件 和 
输出 文件 同 本 章 其 他 文件 一 起 可 供 下 载 。 

输出 文件 的 头 部 信息 大 部 分 是 静态 的 。 然 而 ， 这 里 面 也 有 有 用 的 信息 : 跟踪 文件 名 、 生 成 输出 文 
件 时 参数 sort 的 值 以 及 定位 跟踪 会 话 的 一 行 信息 。 最 后 这 条 信息 只 有 在 指定 了 参数 aggregate=no 时 才 
会 显示 。 请 注意 ， 当 跟踪 文件 包含 多 个 会 话 并 且 指 定 参 数 aggregate=no 时 ， 头 部 信息 里 会 反复 使 用 分 
隅 符 来 区 别 SQL 语 句 和 其 他 会 话 。 

TKPROF: Release 11.2.0.3.0 - Development on Fri Nov 30 23:45:57 2012 

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 


Trace file: DBM11203 ora 28030.trc 


Sort options: prsela exeela fchela 
六 冰冰 玉米 六 六 六 六 六 六 六 冰冰 米 来 玉米 冰冰 六 米 闵 阔 米 玉 冰冰 来 米 冰 玉 六 米 闵 玉米 玉米 玉米 冰 米 米 闵 六 来 米 六 六 来 六 六 闵 米 玉米 六 玉米 米 冰 六 闵 来 闵 玉米 炒米 米 米 六 六 玉 玉米 冰冰 


count = number of times OCI procedure was executed 


cpu = Cpu time in seconds executing 

elapsed = elapsed time in seconds executing 

disk = Number of physical reads of buffers from disk 

query = number of buffers gotten for consistent read 

current = number of buffers gotten in current mode (usually for update) 
IOWS = Number of rows processed by the fetch or execute call 


*#** SESSION ID: (156.29) 2012-11-30 23:21:45.691 

任何 连接 数据 库 或 者 生成 执行 计划 时 的 出 错 信 息 都 会 写 在 头 部 信息 之 后 。 

头 部 信息 之 后 就 是 每 条 SQL 语句 的 信息 : SQL 语 句 的 文本 、 执 行 统计 、 解 析 信 息 、 执 行 计划 以 及 
等 待 事件 。 仅 当 执行 计 划 和 等 待 事件 存储 在 跟踪 文件 中 时 ， 才 会 报告 执行 计划 和 等 待 事件 。 请 记 住 ， 
在 10.2 版 本 中 ， 只 有 当 相 关 游 标 关 闭 后 ， 才 会 将 执行 计划 写 和 人 跟踪 文件 。 这 表明 如 果 应 用 重用 游标 而 
不 关闭 它们 ， 那 么 就 不 会 将 这 些 重用 游标 的 执行 计划 写 入 跟踪 文件 。 

SQL 语句 的 文本 在 有 些 情 况 下 是 格式 化 后 的 。 然 而 并 不 是 所 有 情况 下 都 能 得 到 正确 的 显示 格式 。 
比如 , 在 下 面 的 例子 中 extract 函 数 的 关键 字 FROM 就 与 SELECT 语句 的 FROM 子 句 混 消 。 请 注意 ，SQL ID 只 
对 11.1.0.6 及 以 后 的 版 本 有 效 ， 执 行 计 划 的 值 仅 对 11.1.0.7 及 以 后 的 版 本 有 效 。 


SQL ID: 7wdogdwwgphir Plan Hash: 961378228 


SELECT EXTRACT(YEAR 
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FROM 
D)，ID，PAD FROM T ORDER BY EXTRACT(YEAR FROM D), ID 


执行 统计 会 根据 数据 库 调 用 的 类 型 进行 汇总 并 以 表格 形式 显示 。 每 一 项 性 能 指标 如 下 所 示 。 

口 count: 数据 库 调 用 执行 的 次 数 。 

口 cpu: 花费 在 数据 库 调 用 上 的 CPU 时 间 总 和 ， 单 位 秒 。 

口 elapsed: 花费 在 数据 库 调 用 上 的 运行 时 间 总 和 ， 单 位 秒 。 如 果 此 值 高 于 CPU 时 间 ， 那 么 在 执 
行 统计 下 面 的 部 分 你 会 找到 等 竺 事件， 那里 有 资源 或 同步 点 等 待 的 信息 。 

口 disk: 代表 物理 读 的 块 数 。 注 意 ， 这 不 是 物理 UO 数 。 如 果 这 个 值 比 逻辑 读 大 ( disk>query + 
current )， 就 代表 块 涌 进 了 临时 表 空 间 。 这 种 情况 下 你 可 以 看 到 至 少 读 取 了 33 017 ( 71 499- 
38 474-8 ) 个 块 。 这 需要 稍 后 通过 Row Source Operation 的 统计 和 等 待 事件 来 确认 。 

口 query: 一 致 性 逻辑 读 的 块 数 。 通 常 查询 会 用 到 这 种 逻辑 读 。 

口 current: 在 当前 模式 下 使 用 逻辑 读 读 取 的 块 数 。 通 常 INSERT、DELETE 、MERGE 和 UPDATE 语 句 修 
改 块 会 产生 此 类 逻辑 读 。 

口 rows: 处 理 的 行 数 。 对 于 查询 来 说 ， 这 是 获取 的 行 数 。 对 于 INSERT、DELETE 、MERGE 和 UPDATE 
来 说 这 是 受 影响 的 行 数 。 在 这 里 10001 次 调用 获取 了 1 000 000 行 是 没有 任何 意义 的 。 这 表示 平 
均 来 看 每 次 调用 获取 了 大 约 100 行 。 注 意 这 里 的 100 是 在 PL/SQL 里 设置 的 预 获 取 值 (第 15 章 会 
介绍 关于 预 获 取 值 的 详细 信息 )。 


call count cpu elapsed disk query current TOWS 
Parse 1 0.00 0.00 0 0 0 0 
Execute 1 0.00 0.00 0 0 0 0 
Fetch 10001 6.49 11.92 71499 38474 8 1000000 
total 10003 6.49 11.92 71499 38474 8 1000000 


接 下 来 的 几 行 是 关于 解析 的 基本 概括 信息 。 头 两 个 值 ( Misses in library cache ) 代表 在 解析 和 
执行 调用 期 间 的 硬 解析 数 。 如 果 在 执行 调用 期 间 没 有 硬 解 析 ， 那 么 这 行 就 不 会 显示 。 接 下 来 是 优化 器 
模式 和 解析 此 SQL 语句 的 用 户 ID。 请 注意 用 户 名 〈 本 例 里 是 chris ) 只 有 指定 了 参数 explain 时 才 会 显 
示 。 和 否则 只 会 显示 用 户 ID (这 里 是 34 )。 最 后 一 条 信息 是 递归 深度 。 这 条 信息 仅 是 为 递归 SQL 语句 提 
供 的 。 直 接 由 应 用 执行 的 SQL 语句 深度 为 0。 深 度 2 (本 例 是 1 ) 仅 代表 另 一 个 深度 为 一 ! 的 SQL 语句 执 
行 了 这 个 SQL。 在 这 个 例子 中 ， 深 度 为 0 的 SQL 语句 是 由 SQL*Plus 执 行 的 PL/SQL 块 。 

Misses in library cache during parse: 1 

Misses in library cache during execute: 1 


Optimizer mode: ALL ROWS 
Parsing user id: 34 (CHRIS) (recursive depth: 1) 


在 解析 的 基本 信息 之 后 就 是 执行 计划 了 。 实际 上 ,如 果 指 定 了 参数 explain， 可 能 会 看 到 两 部 分 信 
息 。 第 一 部 分 叫 作 Row Source 0peration， 是 由 多 个 服务 器 进程 写 和 人 跟踪 文件 的 执行 计划 。 第 二 部 分 
叫 作 Execution Plan， 当 指定 参数 explain 后 由 TKPROF 生 成 。 由 于 它 是 后 生成 的 ， 即 使 与 第 一 部 分 不 
同 也 没关系 。 总 之 ， 如 果 你 发 现 两 部 分 不 同 ， 就 以 第 一 部 分 为 准 。 

第 10 章 会 介绍 如 何 阅读 执行 计划 ， 这 里 只 介绍 TKPROF 的 细节 。 对 于 跟踪 文件 里 的 第 一 个 执行 计 
划 ， 两 部 分 执行 计划 都 会 有 执行 计划 里 每 步 执行 返回 的 行 数 ( 注意 ， 不 是 处 理 的 行 数 )。 除 此 之 外 ， 
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11.2.0.2 及 更 高 的 版 本 也 提供 了 所 有 执行 返回 的 平均 行 数 和 最 大 行 数 。 执行 计划 本 身 的 数量 是 由 Number 
of plan statistics captured 值 提供 的 。 

对 于 每 个 row source operation， 还 可 能 会 提供 以 下 运行 时 统计 信息 。 

口 cr 是 一 致 性 逻辑 读 的 块 数 。 

口 pr 是 物理 读 的 块 数 。 

口 pw 是 物理 写 的 块 数 。 

口 time 是 执行 操作 运行 时 间 总 和 , 单位 微 秒 。 请 注意 这 里 显示 的 值 并 不 总 是 那么 精确 。 因 为 为 了 

降低 开销 ， 服 务 进程 会 使 用 采样 来 衡量 。 

口 cost 是 操作 的 估计 成 本 。 这 个 值 自 11.1 版 本 起 开始 启用 。 

口 size 是 操作 返回 的 预计 数据 大 小 ( bytes )。 这 个 值 自 11.1 版 本 起 开始 启用 。 

口 card 是 操作 返回 的 预 估 行 数 。 这 个 值 自 11.1 版 本 起 开始 启用 。 


Number of plan statistics captured: 1 


Rows (1st) Rows (avg) Rows (max) Row Source Operation 


1000000 1000000 1000000 SORT ORDER BY (cr=38474 pr=71499 pw=33035 time=11123996 Us 
cost=216750 size=264000000 card=1000000) 
1000000 1000000 1000000 TABLE ACCESS FULL T (cr=38474 pr=38463 pw=0 time=5674541 Us 
cost=21 size=264000000 card=1000000) 
Rows Execution Plan 


0 SELECT STATEMENT MODE: ALL ROWS 
1000000 SORT (ORDER BY) 
1000000 TABLE ACCESS MODE: ANALYZED (FULL) OF ‘T' (TABLE) 


请 注意 ， 除 了 查询 优化 器 的 估 值 ， 其 他 的 运行 时 统计 信息 都 是 累加 出 来 的 ， 它 包含 了 child row 
source operation 的 值 。 例 如 ，SORT ORDER BY 命令 从 临时 表 空 间 读 取 了 33 036 ( 71 499-38 463 ) 个 块 。 
根据 之 前 的 执行 信息 ( 参见 关于 disk 列 部 分 的 介绍 )， 你 应 该 能 够 估算 出 至 少 读 取 了 33 017 个 块 。 同时 
请 注意 , 虽然 在 以 前 的 版 本 中 这 些 值 只 跟 第 一 次 查询 有 关 , 但 从 11.2.0.2 版 本 开始 它们 变 成 了 所 有 查询 
的 平均 值 ; 在 这 种 情况 下 就 变 得 没有 区 别 了 ， 因 为 只 有 一 次 查询 。 

接 下 来 的 部 分 简要 说 明了 SQL 语句 等 待 的 等 竺 事件。 针对 每 种 类 型 的 等 待 事件 ， 会 提供 以 下 值 。 

口 Times Waited 是 等 待 事件 发 生 的 次 数 。 

口 Max.Wait 是 单个 等 待 事件 等 待 的 最 大 时 间 ， 单 位 秒 。 

口 Toal Waited 是 等 待 事件 的 总 等 待 时 间 ， 单 位 秒 。 


Elapsed times include waiting on following events: 


Event waited on Times Waited Max. Wait Total Waited 
db file sequential read 2 0.00 0.00 
db file scattered read 530 0.06 2 79 
direct path write temp 11002 0.00 0.51 
direct path read temp 24015 0.00 2.41 


理想 情况 下 ， 所 有 等 待 事件 的 等 待 时 间 总 和 应 该 与 执行 统计 信息 里 的 运行 时 间 与 CPU 时 间 的 差 值 
相等 。 这 个 差 值 称 为 未 被 计算 的 时 间 。 
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未 被 计算 的 时 间 


SQL 跟踪 会 提供 每 次 操作 执行 时 数据 库 所 花费 时 间 的 信息 。 理 想 情 况 下 ， 计 算 应 该 非常 精确 
但 是 ， 几 乎 不 能 在 跟踪 文件 里 找到 精确 到 秒 级 以 下 的 准确 信息 。 当 真实 的 运行 时 间 与 跟踪 文件 里 记 
录 的 时 间 不 同时 ,就 存在 未 被 计算 的 时 间 。 
unaccounted-for time = real elapsed time - accounted for time 
出 现 未 被 计算 的 时 间 最 常见 的 原因 如 下 。 
口 最 明显 的 是 跟踪 文件 里 缺少 定时 信息 或 等 待 事件 。 前 者 是 因为 初始 化 参数 timed statistics 被 
设置 成 了 FALSE。 后 者 是 因为 启动 SQL 跟踪 未 包含 级 别 8。 在 这 两 种 情况 下 ， 未 被 计算 的 时 间 总 
是 正 值 。 正 常情 况 下 ， 恰 当 开 启 扩展 的 SQL 跟踪 能 够 避免 这 些 问题 。 
口 通常 来 说 ， 进 程 有 三 种 状态 : 在 CPU 上 运行 、 等 待 请 求 〈 例 如 ， 执 行 磁盘 IO 操作 ) 或 在 执行 
队列 等 待 CPU 资源 。 植 入 代码 能 够 计算 出 前 两 种 状态 所 花费 的 时 间 , 但 是 对 在 执行 队列 等 待 多 
和 久 却 无 能 为 力 。 因 此 ,如 果 发 生 了 CPU 匮乏 , 那么 未 被 计算 的 时 间 ( 始终 为 正 值 ) 可 能 会 很 长 
基本 上 你 可 以 通过 两 种 方法 避免 这 个 问题 : 增加 可 用 CPU 的 数量 或 者 降低 CPU 使 用 率 
口 植 入 代码 可 做 出 精确 的 时 间 测 量 。 然 而 ， 由 于 计算 机 系统 中 计时 器 的 影响 ， 每 次 测量 会 产生 
很 小 的 量化 误差 。 尤 其 是 当 有 大 量 的 测量 时 间 时 ， 这 种 量化 误差 造成 的 未 被 计算 的 时 间 会 很 
明显 。 由 于 计时 器 自身 的 性 质 ， 量 化 误差 可 能 会 导致 未 被 计算 的 时 间 为 正 值 ， 也 可 能 导致 其 
为 负 值 。 遗 憾 的 是 ， 你 对 此 无 能 为 力 。 在 实际 应 用 中 ， 这 个 问题 与 大 量 未 被 计算 的 时 间 无 关 ， 
因为 正 误差 往往 会 与 负 误 差 相抵 消 。 
口 如 果 你 排除 了 列 出 的 这 些 方面 ， 那 么 原因 很 可 能 是 检测 代码 没有 涵盖 整个 代码 。 例 如 ， 写 入 
跟踪 文件 的 时 间 就 不 会 算 在 内 。 这 通常 不 会 是 个 问题 。 但 如 果 跟 踪 文 件 写 入 一 个 性 能 差 的 设 
备 或 需要 生成 跟踪 的 信息 量 非常 大 ， 这 时 可 能 会 产生 大 的 开销 。 在 这 种 情况 下 ， 未 被 计算 的 
时 间 将 始终 为 正 值 。 为 了 避免 这 个 问题 ， 你 应 该 把 跟踪 文件 写 入 一 个 可 以 支撑 正常 吞吐 量 的 
设备 上 。 在 一 些 罕 见 的 情况 下 ， 你 或 许 会 强制 把 跟踪 文件 放 到 RAM 盘 上 。 
Ee ee 20E 信人 
由 于 等 待 事件 的 值 已 经 高 度 聚 合 ， 这 可 以 让 你 只 需要 知道 你 在 等 待 哪 类 资源 。 比 如 ， 根 据 之 前 的 
信息 ， 几 乎 所 有 的 等 待 时 间 都 花 在 了 物理 读 上 ， 但 由 于 信息 已 经 聚合 ， 我 们 看 不 到 具体 信息 ， 比 如 是 
从 哪个 数据 文件 读 取 的 ( 原始 跟踪 文件 里 有 这 个 信息 ), 实际 上 单 块 读 的 等 待 事件 是 db file sequential 
read， 而 多 块 读 (参见 第 9 章 ) 的 等 待 事件 是 db file scattered read。 另 外 ， 涌 入 临时 表 空 间 的 等 待 
事件 是 direct path write temp 和 direct path read temp。 
在 分 析 等 待 事件 时 ， 关 键 是 和 弄 清 楚 与 什么 操作 相关 。 幸 运 的 是 ， 即 使 等 待 事件 种 类 有 几 百 种 ， 经 
常 遇 到 的 也 就 那么 几 种 。 在 Oracle Database Reference 手 册 的 附录 中 有 大 部 分 等 待 事件 的 简介 。 
我 们 继续 分 析 下 一 个 SQL 语句 。 由 于 这 些 信息 结构 与 之 前 的 一 样 ， 因 此 这 里 仅 会 注释 输出 文件 中 
的 新 内 容 或 本 质 的 区 别 。 
DECLARE 
1] count INTEGER; 
BEGIN 


FOR C IN (SELECT extract(YEAR FROM d), id, pad 
FROM 七 
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ORDER BY extract(YEAR FROM d), id) 
LOOP 
NULL; 
END LOOP; 
FOR i IN 1..10 
LOOP 
SELECT count(n) INTO 1 count 
FROM +t 
WHERE id < i*123; 
END LOOP; 
END; 


PL/SQL 块 的 执行 统计 信息 是 有 限 的 。 它 缺少 物理 读 和 逻辑 读 的 信息 ,这 是 因为 递归 SQL 语句 ( 比 
如 之 前 分 析 过 的 查询 ) 使 用 的 资源 与 父 SQL 语 名 无关。 这 表示 你 仅 能 看 到 SQL 语句 〈 或 者 PL/SQL 块 ) 
本 身 使 用 的 资源 。 


call count cpu elapsed disk query current IrOWS 
Parse a 0.00 0.00 0 0 0 0 
Execute 了 0.44 0.40 0 0 0 
Fetch 0 0.00 0.00 0 0 0 0 
total 2 0.45 0.41 07 0 0 1 


由 于 PL/SQL 块 不 是 由 数据 库 递归 执行 的 ， 因此 这 里 不 会 显示 递归 深度 (递归 深度 为 0 ),。 同样 , 也 
不 会 显示 执行 计划 。 
Misses in library cache during parse: 1 


Optimizer mode: ALL ROWS 
Parsing user id: 34 (CHRIS) 


当 网 络 层 发 送 数据 给 客户 端 时 ( 注意 , 通过 网 络 发 送 数据 的 时 间 不 会 计算 在 内 ), 数据 库 等 待 
SQL*Net message to client， 而 数据 库 等 待 客户 端 返 回 消息 时 等 待 SQL*Net message from client。 
因此 ， 对 于 每 个 由 SQL*Net 层 完成 的 往返 ， 你 都 能 看 到 一 对 等 待 事件 。 请 注意 ， 在 低级 别 层 实现 
的 往返 次 数 会 有 些 不 同 。 比 如 ， 在 网 络 层 ( 比如 IP ) 由 于 较 小 的 数据 包 而 完成 大 量 往 返 的 情况 并 
不 少见 。 


Elapsed times include waiting on following events: 
Event waited on Times Waited Max. Wait Total Waited 


SQL*Net message to client r 0.00 0.00 
SQL*Net message from client 1 0.00 0.00 


接 下 来 是 第 二 个 由 PL/SQL 块 执行 的 SQL 语 句 。 结构 信息 与 之 前 的 一 致 。 需 要 指出 的 是 , 这 个 查询 
被 执行 了 10 次 。 对 于 每 次 执行 ， 跟 踪 文 件 都 包含 执行 统计 信息 (启用 了 级 别 16 的 )。 因 此 ，plan 
statistics captured 的 值 是 10， 三 行 数据 中 每 列 都 包含 了 不 同 的 值 ( 122 676 和 1229 )， 并 且 行 来 源 级 
别 的 运行 时 统计 信息 为 平均 值 ( 比如 ，53 的 磁盘 读 除 以 10 次 执行 ， 平 均值 为 5 )。 

SQL ID: 7fjjjfoyvdosm Plan Hash: 4270555908 


SELECT COUNT(N) 
FROM 
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T WHERE ID «< :B1 *123 


call count cpu elapsed disk query current IOWS 
Parse 1 0.00 0.00 0 0 0 0 
Execute 10 0.00 0.00 0 0 0 0 
Fetch 10 0.00 0.02 53 303 0 10 
Total 21 0.01 0.02 53 303 0 10 


Misses in library cache during parse: 1 

Misses in library cache during execute: 1 
Optimizer mode: ALL ROWS 

Parsing user id: 34 (CHRIS) (recursive depth: 1) 
Number of plan statistics captured: 10 


Rows (1st) Rows (avg) Rows (max) Row Source Operation 


4 1 1 SORT AGGREGATE (cr=30 pr=5 pw=0 time=2607 us) 
122 676 1229 TABLE ACCESS BY INDEX ROWID T (cr=30 pr=5 pw=0 time=2045 US 
cost=8 size=1098 card=122) 
122 676 1229 INDEX RANGE SCAN T_PK (cr=4 pr=0 pw=0 time=872 US cost=3 


size=0 card=122)(object id 20991) 
Rows Execution Plan 
0 SELECT STATEMENT MODE: ALL_ ROWS 
1 SORT (AGGREGATE) 
122 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'T' (TABLE) 
122 INDEX MODE: ANALYZED (RANGE SCAN) OF 'T_PK' (INDEX (UNIQUE) 


) 
Elapsed times include waiting on following events: 
Event waited on Times Waited Max. Wait Total Waited 
db file sequential read 53 0.00 0.02 


为 了 获取 被 使 用 的 对 象 信息 ( 比如 对 象 统计 信息 )， 数 据 库 引擎 递归 执行 最 后 的 SQL 语 句 。 此 外 ， 
查询 优化 器 会 使 用 此 信息 来 计算 出 最 有 效率 的 执行 计划 。 解 析 这 条 SQL 的 用 户 是 SYS， 因 此 你 可 以 判 
断 是 由 数据 库 引 擎 执行 的 这 条 SQL 语句 。 根 据 递归 深度 为 2， 可 以 推断 这 条 SQL 语句 需要 解析 深度 为 1 
的 SQL， 比 如 在 输出 文件 中 的 第 一 个 SQL 语句 。 


SQL ID: 96g93hntrzjtr Plan Hash: 2239883476 


select /*+ rule */ bucket cnt, row cnt, cache cnt, null cnt, timestamp#, 
sample size, minimum, maximum, distcnt, lowval, hival, density, col#, 
spare1, spare2, avgcln 

from 

hist head$ where obj#=:1 and intcol#=:2 


call count cpu elapsed disk query current IOWS 


| 

0 0 
12 0 
12 0 
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Execute 4 0.00 0.00 0 
Fetch 4 0.00 0.01 5 
total 8 0.00 0.01 5 


Misses in library cache during parse: 0 
Optimizer mode: RULE 
Parsing user id: SYS (recursive depth: 2) 
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本 例 中 由 于 表 来 源 的 信息 没有 记录 在 跟踪 文件 里 , 并 且 用 户 CHRIS 没 有 这 条 SQL 语句 涉及 的 对 象 权 
限 ， 因 此 没有 显示 执行 计划 ( 参见 第 10 章 关于 执行 EXPLAIN PLAN 语句 所 需 权限 的 详细 信息 )。 输 出 部 分 


接 下 来 是 等 待 事件 。 


Elapsed times include waiting on following events : 
Event waited on 


Times Waited Max. Wait Total Waited 


db file sequential read 5 


在 所 有 SQL 语句 的 报告 后 ， 你 可 以 看 到 执行 统计 信息 、 解 析 和 等 待 事件 的 综合 


要 注意 的 就 是 非 递 归 SQL 从 递归 SQL 里 分 离 出 来 。 
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS 


query Current 
0 0 

226 0 

0 0 

226 0 


call count cpu elapsed disk 
Parse 2 0.00 0.00 0 
Execute bE} 0.45 0.42 20 
Fetch 0 0.00 0.00 0 
total 5 0.45 0.42 20 


Misses in library cache during parse: 2 
Misses in library cache during execute: 1 


Elapsed times include waiting on following events: 
Event waited on 


Times Waited Max. Wait Total 


SQL*Net message to client 2 
SQL*Net message from client 2 


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS 


0.00 

0.00 
query current 
0 0 
0 0 
38832 8 
38832 8 


ITOWS 

0 

3 

0 

3 
Waited 
0.00 
0.00 

ITOWS 

0 

0 

1000028 

1000028 


call count cpu elapsed disk 
Parse 2 0.00 0.00 0 
Execute 29 0.00 0.00 0 
Fetch 10037 6.50 11.97 71569 
Total 10068 6.50 11.97 71569 


Misses in library cache during parse: 2 
Misses in library cache during execute: 2 


Elapsed times include waiting on following events: 


统计 。 这 里 唯一 需 
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Event waited on Times Waited Max. Wait Total Waited 
db file sequential read 72 0.00 0.04 
db file scattered read 530 0.06 2.79 
direct path write temp 11002 0.00 0.51 
direct path read temp 24015 0.00 2.41 


接 下 来 的 几 行 是 对 当前 会 话 的 SQL 数量 进行 概括 ， 包 括 由 数据 库 引 擎 递归 执行 的 数量 和 EXPLIAN 
PLAN 执行 的 次 数 : 
5 User SQL statements in session. 
13 internal SQL statements in session. 


18 SQL statements in session. 
2 statements EXPLAINed in this session. 


现在 ,输出 文件 已 经 包含 了 跟踪 文件 的 所 有 信息 。 首 先 ， 你 能 看 到 跟踪 文件 名 、 其 版 本 和 用 于 分 
析 的 参数 sort 的 值 。 接 着 是 所 有 会 话 数 和 SQL 语句 。 在 这 个 例子 中 , 跟踪 文件 里 少 了 14 ( 18-4 ) 行 SQL 
语句 是 因为 指定 了 参数 print=4。 同 时 也 记录 了 执行 EXPLAIN PLAN 的 表 信 息 。 最 后 ， 是 所 有 SQL 语句 的 
总 运行 时 间 〈 以 秒 为 单位 )。 我 个 人 更 愿意 在 跟踪 文件 的 头 部 看 到 最 后 这 部 分 信息 ， 因 为 每 次 我 打开 
TKPROF 的 输出 文件 时 ， 总 是 最 先 浏览 最 后 部 分 。 关 键 是 要 知道 整个 跟踪 文件 花费 多 少时 间 ， 否 则 你 
无 法 判断 一 个 SQL 语句 对 于 总 响应 时 间 的 影响 程度 。 
Trace file: DBM11203 ora 28030.trc 
Trace file compatibility: 11.1.0.7 
Sort options: prsela exeela fchela 
1 session in tracefile. 
5 User SQL statements in trace file. 
13 internal SQL statements in trace file. 
18 SQL statements in trace file. : 
18 unique SQL statements in trace file. 
2 SQL statements EXPLAINed using schema: 
CHRIS.prof$plan table 
Default table was used. 
Table was created. 
Table was dropped. 
46125 lines in trace file. 
12 elapsed seconds in trace file. 


3.1.6 ”使 用 TVD$XTAT 


Trivadis Extended Tracefile Analysis Tool( TVD$XTAT ) 是 命令 行 工 具 。 与 TIKPROF 一 样 ,TVDSXTAT 
的 主要 功能 是 输入 原始 跟踪 文件 ， 生 成 一 个 格式 化 后 的 文件 。 输 出 文件 可 以 是 HTML 或 者 文本 文件 。 

最 简单 的 分 析 是 通过 仅 指 定 输入 和 输出 文件 来 执行 的 。 在 下 面 的 例子 中 ， 输 入 文件 是 
DBM11106_ora_6334.trc， 输 出 文件 是 DBM11106_ora_6334.html: 


tvdxtat -i DBM11106 ora 6334.trc -0 DBM11106 ora 6334.html 
1. 为 什么 TKPROF 不 能 满足 需要 


1999 年 未 ， 通 过 Oracle Support 文 档 Interpreting Raw SQL_TRACE and DBMS_SUPPORTSTART_ 
TRACE output( 39817.1 ), 我 第 一 次 接触 到 扩展 SQL 跟 踪 。 从 那 时 开始 , 我 就 明白 要 理解 应 用 连接 Oracle 
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数据 库 后 做 了 什么 ， 这些 信息 是 必 不 可 少 的 。 同 时 ， 令 我 非常 失望 的 是 ; 没有 工具 能 分 析 扩 展 的 SQL 
跟踪 文件 以 利用 它们 的 内 容 。 我 注意 到 那个 时 候 TKPROF 还 不 能 提供 等 待 事件 信息 。 利 用 命令 行 工具 
(比如 awk ) 手工 从 原始 跟踪 文件 里 提取 信息 花 了 我 大 量 的 时 间 ,， 因此 我 决定 自己 写 一 个 分 析 工 具 , 并 


将 其 命名 为 TVD$XTAT。 
当前 ，TKRPFO 可 以 提供 等 待 事件 信息 ， 但 仍 存在 五 个 主要 问题 ， 这 些 问题 已 经 在 TVDSXTAT 中 
得 到 了 解决 。 


口 只 要 指定 了 参数 sort， 那 么 SQL 语句 之 间 的 联系 就 没有 了 。 

口 数据 只 能 以 聚合 的 形式 显示 。 因 此 ,丢失 了 很 多 有 用 的 信息 。 

口 不 提供 绑 定 变量 的 信息 。 

口 在 TKPROF 里 ， 当 SQL 语句 执行 时 间 不 计算 在 elapsedtime 中 时 ,使 用 空闲 等 待 事件 代替 ( 比如 
SQL*Net message from client )。 这 样 做 的 结果 就 是 当 SQL 语句 根据 elapsed time 进 行 排序 时 ， 
输出 结果 会 造成 误导 ， 或 者 在 一 些 极端 情况 下 ， 出 现 大 量 无 法 解释 的 时 间 消 耗 。 

口 当 跟 踪 文 件 里 没有 SQL 语句 文本 ( i ve IN CURSOR 和 END OF STMT 之 间 的 文本 ) 


时 ，TKPROF 不 会 记录 关于 这 些 SQL 语 句 的 细节 信息 ; 而 只 是 把 它 记 录 到 输出 文件 最 后 资源 使 
用 率 的 统计 中 。 请 注意 ， rt 那么 跟踪 文件 里 就 不 会 记录 
SQL 语句 的 文本 。 允 

2. 安装 


以 下 是 安装 TVDSXTAT 的 步骤 。 

(1) 从 http://top.antognini.ch 下 载 ( 免费 软件 ) TVD$XTAT。 

(2) 将 文件 解压 到 一 个 空 目 录 。 

(3) 修改 用 于 启动 TVDSXTATI 的 shell 脚 本 ( 根据 操作 系统 不 同 , 要 么 是 tvdxtat.cmd, 要 么 是 tvdxtat.sh ) 
中 的 变量 java_home 和 tvdxtat_home。 前 者 引用 的 是 JRE ( 版 本 1.4.2 或 以 上 版 本 ) 的 安装 目录 。 后 者 引 
用 的 是 分 发 文件 的 解压 目 录 。 

(4) 根据 需要 更 改 命令 行 参数 的 默认 值 。 你 需要 更 改 config 目 录 里 的 tvdxtat.properties 文 件 。 可 
以 定制 默认 配置 ， ph 用 在 每 次 运行 TVDSXTAT 时 指定 所 有 参数 。 

(5) 也 可 以 根据 需要 更 改 日 志 配置 。 为 此 ， 你 需要 更 改 config 目 录 里 的 logging.properties 文 件 。 
默认 情况 下 ，TVDSXTAT 会 显示 错误 和 警告 信息 。 通 常 没有 必要 修改 它 。 


3. TVD$XTAT 参 数 
如 果 执 行 TVDS$XTAT 时 未 附加 任何 参数 , 那么 返回 的 是 完整 的 参数 列表 , 其 中 包含 一 个 简短 描述 。 
请 注意 ， 针 对 每 个 参数 ， 都 有 一 个 短 格式 〈 例如-c ) 和 一 个 长 格式 ( 例如--cleanup )。 


usage: tvdxtat [-c nolyes] [-f <int>] [-1 “int>] [-r 7|8|9|10|11|12] 

[-s nolyes] [-t <template>] [-w no|yes] 

[-x severe|lwarning|info|fine|finer] -i <input> -o <output> 
-C,--Cleanup remove temporary XML file (no|yes) 
-f,--feedback display progress every x lines (integer number >= 0, no 

progress = 0) 

-h,--help display this help information and exit 
-i,--input input trace file name (valid extensions: trc|gz|zip) 
-1,--limit limit the size of lists (e.g. number of statements) in 
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里 我 


the output file (integer number >= 0, unlimited = 0) 


-0,--Output output file name (a temporary XML file with the same 
name but with the extension xm]l is also created) 

-I,--release major release of the database engine that generated the 
input trace file (7|8|9|10|11|12) 

=S3~=SYS report information about SYS recursive statements 
(no|yes) 


-t,--template name of the XSL template used to generate the output 
file (html|text) 


-V,--VerSion print product version and exit 

-W,--wait report detailed information about wait events (no|yes) 
-x,--logging logging level (severe|warning|info|fine|finer) 

各 个 参数 的 作用 如 下 。 


口 input :指定 输入 文件 ,输入 文件 必须 是 包含 一 个 或 多 个 跟踪 文件 信息 的 跟踪 文件 ( 后 级 名 .trc ) 
或 压缩 文件 (后缀 名 .gz 或 .zip )。 但 要 注意 ， 只 会 有 一 个 跟踪 文件 从 .zip 文 件 中 提取 出 来 。 

口 output: 指定 输出 文件 。 在 工具 执行 时 会 生成 一 个 与 输出 文件 同名 但 后 缀 名 为 .xml 的 临时 XML 
文件 。 请 注意 ， 这 会 覆盖 其 他 与 输出 文件 同名 的 文件 。 

口 cleanup: 指定 在 工具 执行 结束 后 是 否 删除 临时 生成 的 XML 文件 。 通 常情 况 下 ， 会 设置 为 yes。 
此 参数 仅 在 开发 阶段 用 于 检查 中 间 结 果 时 才 显 示 出 甚 重要 性 。 

口 feedback: 指定 是 否 显示 进程 信息 。 在 处 理 非常 大 的 跟踪 文件 时 , 该 参数 可 以 帮助 你 得 知 当 前 
分 析 的 状态 。 该 参数 指定 的 是 新 消息 产生 时 显示 的 行 数 。 如 果 设 置 为 0, 就 不 会 显示 进程 信息 . 

口 help: 指定 是 否 显 示 帮 助 信息 。 该 参数 不 能 与 其 他 参数 一 起 使 用 。 

口 limit: 设置 输出 文件 中 列表 ( 比如 ，SQL 语 句 的 列表 ， 等 待 和 绑 定 变量 的 列表 ) 的 最 大 行 数 。 
如 果 设 置 成 0， 那 么 就 没有 限制 。 

口 release: 指定 生成 输入 跟踪 文件 的 数据 库 主要 版 本 ( 即 7、8、9、10、11 或 12 )- 

口 sys: 指定 输出 文件 中 是 和 否 显 示 由 sys 用 户 执行 的 递归 SQL 语句 信息 。 通 常设 置 成 no。 

口 template: 指定 生成 输出 文件 的 XSL 模 板 名 。 默 认 情 况 下 ， 有 两 个 模板 可 用 : html.xs1 和 
text.xsl。 前 者 生成 HTML 输 出 文件 ,后 者 生成 文本 输出 文件 。 你 可 以 修改 默认 模板 ， 也 可 以 
创建 新 模板 。 这 样 就 可 以 完全 定制 输出 文件 。 模 板 必 须要 放 在 templates 文 件 夹 中 。 

口 version: 指定 是 否 显示 TVD$XTAT 版 本 号 。 该 参数 不 能 与 其 他 参数 一 起 使 用 。 

口 wait: 指定 是 否 显 示 等 待 事件 的 详细 信息 。 开 启 此 功能 ( 即 ， 设 置 参 数 为 yes ) 可 能 会 在 处 理 
时 造成 很 大 的 开销 。 因 此 , 建议 首先 设 成 no， 当 基础 的 等 待 信息 无 法 满足 分 析 时 ,再 把 它 设 置 
成 yes 重 新 运行 一 次 。 

口 logging: 控制 日 志 级 别 。 该 参数 可 设置 的 值 为 : severe 、warning、info、fine 和 finer。 该 参 
数 仅 在 诊断 工具 运行 时 有 用 。 

4. 解释 TVD$XTAT 的 输出 


这 部 分 使 用 与 TKPROF 相 同 的 跟踪 文件 。 鉴 于 TVD$XTAT 的 输出 结构 是 根据 TKPROF 设 计 的 ， 这 
只 会 介绍 TVDS$XTAT 特 有 的 部 分 。 我 使 用 如 下 命令 来 生成 输出 文件 : 


tvdxtat -i DBM11203_ ora 28030.trc -0 DBM11203 ora 28030.txt -s no -W yes -t text 


注意 ， 跟 踪 文 件 以 及 输出 的 HTML 文 件 都 随 本 章 的 其 他 文件 一 起 可 供 下 载 。 
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输出 文件 最 开始 是 输入 跟踪 文件 的 汇总 信息 。 其 中 最 重要 的 是 跟踪 文件 里 的 interval 和 transaction 数 。 


Database Version 

六 六 米 米 米 闵 冰冰 玉米 闵 六 六 六 六 六 

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production 
With the Partitioning, Automatic Storage Management, Oracle Label Security, OLAP, 
Data Mining and Real Application Testing options 


Analyzed Trace File 
冰 六 六 闵 米 米 来 六 来 术 闲 冰 闵 六 闵 闵 术 冰 六 


/uo0/app/oracle/diag/rdbms/dbm11203/DBM11203/trace/DBM11203_ ora 28030.trc 


Interval 
六 六 冰冰 米 玉 六 六 


Beginning 30 Nov 2012 23:21:45.691 
End 30 Nov 2012 23:21:58.097 
Duration 12.407 [s] 


Transactions 
六 来 来 来 洲 闵 来 来 闵 宁 冰冰 


Committed 0 
Rollbacked 0 


分 析 输 出 文件 要 从 汇总 资源 使 用 分 析 开始 。 这 里 的 处 理 用 了 12.407 秒 。 大 约 56% 的 时 间 用 在 了 CPU 
执行 上 ， 大 约 24% 用 于 读 写 临时 文件 ( direct path read temp 和 direct path write temp )，23% 用 于 
读 取 数据 文件 ( db file scattered read 和 db file sequential read )。 总 之 就 是 大 部 分 时 间 用 在 了 CPU 
执行 上 ， 剩 下 的 时 间 用 来 处 理 磁盘 LO。 请 注意 ， 示 被 计算 的 时 间 是 明确 给 出 的 。 


Resource Usage Profile 
玉米 六 玉米 六 冰冰 来 冰冰 六 米 米 玉米 六 冰冰 玉 六 玉 


Total Number of Duration per 
Component Duration [s] % Events Events [s] 
CPU 6.969 56.171 n/a n/a 
db file scattered read 2.792 22.502 530 0.005 
direct path read temp 2.417 19.479 24,015 0.000 
direct path write temp 0.513 4.136 11,002 0.000 
db file sequential read 0.041 0.326 72 0.001 
SQL#Net message from client 0.001 0.008 2 0.001 
SQL*Net message to client 0.000 0.000 2 0.000 
unaccounted-for -0.325 -2.623 n/a n/a 
Total 12.407 100.000 


注意 TVDSXTAT 会 根据 响应 时 间 对 列表 进行 排序 。 没 有 选项 可 改变 这 一 行为 ， 因 为 只 有 这 种 排序 
才 对 研究 性 能 问题 有 意义 。 


通过 大 致 的 描述 只 能 知道 数据 库 引 擎 花费 的 时 间 。 为 了 继续 分 析 ， 就 需要 找 出 哪些 SQL 语句 消耗 
了 大 量 的 时 间 。 为 了 达到 这 个 目的 , 在 汇总 资源 使 用 分 析 之 后 是 一 个 包含 所 有 非 递归 SQL 语句 的 列表 。 
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这 样 ， 你 就 能 知道 单独 一 个 SQL 语句 ( 实际 上 是 PL/SQL 块 ) 在 整个 执行 时 间 中 占用 的 比例 。 请 注意 下 
面 的 列表 中 总 和 并 不 是 100%， 因 为 未 被 计算 的 时 间 被 省 略 了 。 


The ;input file contains 18 distinct statements, 15 of which are recursive. 
In the following table, only non-recursive statements are reported. 


Total Number of Duration per 
Statement ID Type Duration [s] % Executions Execution [s] 
#1 PL/SOL 12.724 102.561 1 12.724 
#5 PL/SQL 0.006 0.045 和 0.006 
#9 PL/SQL 0.002 0.016 1 0.002 
Total 12.732 102.623 


下 一 步 通常 来 说 应 该 找到 占用 最 多 执行 时 间 的 SQL 信 息 。 为 了 能 更 容易 找到 SQL，TVD$XTAT 为 
每 个 SQL 生成 了 一 个 标识 符 ( 上面 列表 里 的 Statement ID 列 )。 在 HTML 类 型 的 输出 文件 中 ， 你 可 以 单 
击 对 应 标识 符 来 找到 SQL 语句 的 详细 信息 。 在 文本 类 型 的 输出 文件 中 ， 你 必须 手动 搜索 字符 串 
“STATEMENT #1”。 

接 下 来 的 信息 来 自 每 条 SQL 语句 : 执行 环境 的 基本 信息 、SQL 语 句 的 执行 统计 信息 、 执 行 计划 、 
执行 用 到 的 绑 定 变量 和 等 竺 事件 。 只 有 在 跟踪 文件 里 记录 了 执行 计划 ， 绑 定 变量 和 等 待 事件 的 信息 才 
会 在 这 里 显示 。 

首先 ， 是 执行 环境 的 基本 信息 和 SQL 语句 文本 。 请 注意 ， 会 话 属性 信息 仅 在 设置 之 后 才 会 显示 。 
比如 ， 这 里 的 属性 动作 名 因为 应 用 没有 设置 而 不 会 显示 。 男 外 需要 注意 的 是 ， 从 11.1 版 本 开始 ， 生 成 
跟踪 文件 才能 使 用 SQL ID。 


Session ID 156.29 
Service Name SYS$USERS 
Module Name SOL*Plus 
Parsing User 34 
Hash Value 166910891 
SQL ID 15p0p084z5qxb 
DECLARE 
1 count INTEGER; 
BEGIN 
FOR ¢ IN (SELECT extract(YEAR FROM d), id, pad 
FROM 七 
ORDER BY extract(YEAR FROM d), id) 
LOOP 
NULL; 
END LOOP; 
FOR i IN 1..10 
LOOP 
SELECT count(n) INTO 1 count 
FROM + 
WHERE id < i*123; 
END LOOP; 


END; 
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执行 统计 信息 会 根据 数据 库 调用 类 型 聚合 并 以 表格 形式 显示 。 由 于 表 结 构 是 根据 TKPROF 生 成 的 ， 
因此 各 列 意 义 相 同 。 但 这 里 又 新 增 了 两 列 : Misses 和 LI0。 前 者 是 每 类 调用 期 间 的 硬 解 析 数 。 后 者 是 列 
Consistent 和 Current 的 总 和 。 同 时 请 注意 TVD$SXTAT 提 供 了 两 张 表 。 第 一 张 表 包含 所 有 与 当前 语句 相 
关 的 递归 SQL 统计 信息 。 第 二 张 表 与 TIKPROF 一 样 ， 不 包含 统计 信息 。 

Database Call Statistics with Recursive Statements 


水 来 来 来 来 求 来 水 来 来 来 来 来 来 来 来 来 来 来 阔 素来 来 求 来 炒 来 阔 水 炒 求 来 米 来 炒 求 来 来 来 米 素 来 来 来 米 来 求 素 求 水 


Call Count Misses CPU Elapsed PIO LIO Consistent Current Rows 


Parse 1 1 0.005 0.006 人” 20 20 0 0 
Execute 但 0 6.957 12.387 71,562 38,820 38,812 8 1 
Fetch 0 0 0.000 0.000 0 0 0 0 0 
Total 2 1 6.962 12.393 71,569 38,840 38,832 8 和 


Database (Call Statistics without Recursive Statements 
米 米 六 六 六 玉 玉米 冰冰 六 冰冰 六 六 冰 冰冰 六 六 六 闵 米 六 六 六 六 六 冰冰 来 六 六 冰 六 六 来 闵 玉 六 闲 六 六 六 玉米 玉 闵 米 闵 六 六 六 


Cal Count Misses CPU Elapsed PIO LIO Consistent Current Rows 


Parse 1 1 0.005 0.004 0 0 0 0 0 
Execute 1 0 0.448 0.410 0 0 0 0 
Fetch 0 0 0.000 0.000 0 ”到 0 0 0 
Total 2 1 0.453 0.414 0 0 0 0 1 


在 这 里 ， 根 据 执行 统计 信息 可 发 现 当 前 SQL 语句 几乎 没有 花费 时 间 。 这 点 同样 在 下 面 的 资源 使 用 
分 析 中 得 以 体现 。 实 际 上 ， 这 里 显示 大 约 96% 的 时 间 用 在 了 递归 SQL 语句 上 。 


Component Duration [s] % Events Events [s] 
recursive statements 12.271 96.437 n/a n/a 
CPU 0.453 3.560 n/a n/a 
SQL*Net message from client 0.000 0.003 1 0.000 
SQL*Net message to client 0.000 0.000 1 0.000 
Total 12.724 100.000 


在 资源 使 用 分 析 之 后 列 出 的 都 是 那些 递归 SQL 语句 。 你 可 以 看 到 statement 2 的 SQL 语句 , 这 是 一 个 
SELECT 查询 ， 占 用 了 96% 的 响应 时 间 。 请 注意 ， 这 里 除了 statement3 的 SQL 语句 以 外 ， 其 他 都 是 由 数据 
库 引擎 ( 比如 ， 在 解析 阶段 ) 产生 的 ， 因 此 带 有 SYS recursive 标 签 。 


7 recursive statements were executed. 


Total 
Statement ID Type Duration [s] % 
#2 SELECT 12.234 96.150 
#3 SELECT 0.033 0.263 
#7 SELECT (SYS recursive) 0.003 0.022 
#11 SELECT (SYS recursive) 0.000 0.001 
#12 SELECT (SYS recursive) 0.000 0.001 
#14 SELECT (SYS recursive) 0.000 0.001 
#16 SELECT (SYS recursive) 0.000 0.000 


Total 12.252 96.286 

由 于 statement 2 的 SQL 占用 了 最 多 的 响应 时 间 ， 因 此 你 需要 继续 深入 并 获得 更 多 的 详细 信息 。 它 
的 结构 基本 上 与 statement 1 SQL 一 样 ， 但 是 还 包括 附加 信息 。 在 显示 执行 环境 的 部 分 ， 你 可 以 看 到 递 
归 级 别 ( 记 住 ， 应 用 是 在 级 别 0 执行 得 SQL ) 和 父 SQL 的 statement 编 号 。 后 者 可 以 保证 不 会 丢失 SQL 语 
句 之 间 的 联系 ( TKPROF 就 没有 这 种 联系 )。 


Session ID 156.29 
Service Name SYS$USERS 
Module Name SQL*Plus 
Parsing User 34 

Recursive Level 1 

Parent Statement ID 1 

Hash Value 955957303 

SQL ID 7wdOogdwwgph1r 


SELECT EXTRACT(YEAR FROM D), ID, PAD FROM T ORDER BY EXTRACT(YEAR FROM D), ID 
下 一 步 , 如 果 跟 踪 文 件 里 有 执行 计划 , 那么 你 应 该 能 找到 。 它 的 格式 与 TKRPOF 生 成 的 输出 相同 : 


Execution Plan 


米 米 阔 米 玉米 玉米 米 闵 末 冰 来 玉 
Optimizer Mode ALL_ROWS 
Hash Value 961378228 


Rows Operation 


1,000,000 SORT ORDER BY (cr=38474 pr=71499 pw=33035 time=11123996 US 
cost=216750 size=264000000 card=1000000) 
1,000,000 TABLE ACCESS FULL T (cr=38474 pr=38463 pw=0 time=5674541 Us 
cost=21 size=264000000 card=1000000) 


通常 对 于 所 有 SQL 语句 都 是 一 样 的 ， 执 行 计 划 后 面 是 执行 统计 信息 、 资 源 使 用 分 析 ， 有 可 能 也 有 
级 别 2 的 递归 SQL 语句 (你 当前 看 到 的 是 级 别 1 的 SQL 语句 )。 在 本 例 中 ,递归 SQL 只 占 了 不 到 1% 的 响 
应 时 间 。 换 名 话说 ，statement 2 的 SQL 语句 占用 了 所 有 的 啊 应 时 间 : 


Database Call Statistics with Recursive Statements 
来 来 来 玉 末 六 来 米 来 来 来 来 来 来 冰冰 玉 来 素来 来 来 玉 闵 闵 来 米 来 环 来 来 来 来 闵 来 米 半 素来 来 来 阔 来 阔 素 来 来 本 玉 冰 


Call Count Misses CPU Elapsed PIO LIO Consistent Current Rows 
Parse 4 10.004 0.010 " 32 32 0 0 
Execute 1 0.000 0.000 0 0 0 0 0 
Fetch 10,001 0 6.492 11.926 71,499 38,482 38,474 8 1,000,000 
Total 10,003 2 6.496 11.936 71,506 38,514 38,506 8 1,000,000 
Average (per row) 0 0 0.000 0.000 0 0 0 0 1 


Database Call Statistics without Recursive Statements 
六 阔 玉 来 米 末 闵 闵 冰 永 米 闵 冰 米 来 闵 玉 冰 米 冰冰 六 来 永 来 米 冰 六 玉 来 闲 来 冰 来 玉米 玉 米 来 来 未 闵 率 本 来 玉米 闵 玉 永 玉米 六 


Call Count Misses CPU Elapsed PIO LIO Consistent Current Rows 
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Parse 10.001 0.001 0 9 9 0 0 
Execute 于 1 0.000 0.000 0 0 0 0 0 
Fetch 10,001 0 6.492 11.926 71,499 38,482 38,474 8 1,000,000 
Total 10,003 2 6.493 11.927 71,499 38,491 38,483 8 1,000,000 
Average (per row) 0 0 0.000 0.000 0 0 0 0 


Resource Usage Profile 
米 米 米 闵 阔 米 水 米 六 洒水 六 六 米 闵 米 冰冰 玉米 冰冰 


Total Number of Duration per 
Component Duration [s] % Events Events [s] 
CPU 6.493 53.071 n/a n/a 
db file scattered read 2.792 22.818 530 0.005 
direct path read temp 2.417 19.753 24,015 0.000 
direct path write temp 0.513 4.194 11,002 0.000 
recursive statements 0.020 0.161 n/a n/a 
db file sequential read 0.000 “0.002 2 0.000 
Total 12.234 100.000 
6 recursive statements were executed. a 

Total 

Statement ID Type Duration [s] % 
#4 SELECT (SYS recursive) 6.015 06121 
#6 SELECT (SYS recursive) 0.004 0.032 
#10 SELECT (SYS recursive) 0.001 0.008 
#13 SELECT (SYS recursive) 0.000 0.001 
#17 SELECT (SYS recursive) 0.000 0.000 
#18 SELECT (SYS recursive) 0.000 0.000 
Total 0.006 0.050 


在 以 上 的 资源 使 用 分 析 里 ， 等 待 事件 被 分 组 汇总 显示 。 为 了 获得 更 多 信息 ， 以 下 显示 的 是 针对 资 
源 使 用 分 析 里 每 部 分 的 直方 图 。 在 本 例 中 ,显示 的 信息 与 statement 2 SQL 的 等 待 事件 db file scattered 
read 相 关 。 请 注意 ,等 待 事件 根据 区 间 ( 列 Range ) 进行 分 组 。 例 如， 你 可 以 看 到 52% 的 等 待 事件 持续 
了 4096~8192 微 秒 。 由 于 多 块 读 的 等 待 事件 是 db file scattered read， 查 看 磁盘 IO 操作 ( 列 Blocks per 
Event ) 读 取 的 平均 块 数 也 能 获取 有 用 的 信息 。 


Total Number of Duration per Blocks per 
Range [ns] Duration % Events % Event [hs] Blocks Event 
256 [| duration < 512 0.003 0.111 i 半 443 56 8 
512 [| duration < 1024 0.008 0.288 9 892 D2 8 
1024 [| duration < 2048 0.033 1.191 18 3 1,847 826 46 
2048 0 duration < 4096 0.517 18.525 166 31 35115 ‘Tt;627 70 
4096 1 duration «< 8192 1.465 52.459 264 50 5,547 20,742 79 
8192 1 duration < 16384 0.579 20.736 60 六 计 9,648 4,722 79 
16384 [| duration < 32768 0.126 4.496 5 1 25,1404 336 67 
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32768 1 duration «< 65536 0.061 2.195 1 0 61,274 81 81 


Total 2.792 100.000 530 100.000 5,267 38,462 73 

如 果 开 启 了 详细 信息 显示 ( 使 用 参数 wait )， 之 前 的 直方 图 可 能 会 显示 更 多 的 细节 。 但 这 与 等 待 
事件 类 型 关系 很 大 。 实 际 上 , 许多 事件 没有 附加 信息 。 磁盘 LO 操作 相关 的 等 待 事件 也 只 是 显示 文件 级 
别 的 信息 。 例 如 ， 以 下 表格 显示 statement 2 SQL 的 等 待 事件 db file scattered read 的 信息 。 在 这 个 例 
子 中 ， 在 2.792 秒 时 间 里 磁盘 1/O 在 data file 4 上 执行 了 530 次 操作 。 这 代表 平均 每 次 磁盘 IO 操作 持续 了 
5.267 毫 秒 ( 注意 此 表单 位 : 毫秒 )。 


File Total Number of Duration per 
Number Duration [s] % Events % Blocks [b] % Event [ps] 
4 2.792 100.000 530 100.000 38,462 100.000 5,267 


与 你 预料 的 一 样 , 所 有 SQL 语句 的 结构 都 是 相同 的 。 但 是 有 一 块 信息 在 前 两 条 SQL 语句 里 不 显示 。 
让 我 们 引用 一 部 分 使 用 绑 定 变量 的 SQL 语句 的 信息 来 举例 。 正 如 输出 statement 3 SQL 显示 的 那样 ， 如 
果 绑 定 变 量 信息 已 经 记录 在 跟踪 文件 里 ,那么 TVDSXTAT 会 显示 它们 的 数据 类 型 和 值 。 另 外 ， 如 果 存 
在 多 次 执行 (本 例 中 是 10 次 )， 绑 定 变 量 会 用 执行 次 数 标记 。 请 看 下 面 的 例子 。 


Session ID 156.29 
Service Name SYS$USERS 
Module Name SQL*Plus 
Parsing User 34 

Recursive Level 1 

Parent Statement ID 1 

Hash Value 1035370675 
SQL ID 7fjjfoyvdosm 


SELECT COUNT(N) FROM 下 WHERE ID < :B1 *123 


Bind Variables 
米 来 来 六 六 冰冰 来 玉米 水 玉米 六 


10 bind variable sets were used to execute this statement. 


Number of 
Execution Bind Datatype Value 


1 1 NUMBER i 
2 1 NUMBER 2 坟 
3 4 NUMBER "3" 
4 1 NUMBER "a 
5 1 NUMBER 有 ;六 
6 NUMBER "三 
7 1 NUMBER 区 
8 1 NUMBER 9 
9 1 NUMBER "g" 
10 小 NUMBER “和 


总 之 ， 虽然 执行 了 大 量 SQL 语 句 (一 共 是 18 条 )，statement 2 的 SQL 占 用 了 大 多 数 的 响应 时 间 。 因 
此 ， 为 了 提高 性 能 ， 这 条 SQL 应 该 需要 优化 或 者 删除 。 
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3.2 ”探查 PL/SQL 代码 


数据 库 引 擎 提供 了 两 个 在 PL/SQL3 引 | 擎 中 集成 的 探查 器 ， 以 便 在 探查 PL/SQL 代 码 时 使 用 。 一 个 是 
通过 包 dbms_profiler 进 行 管理 的 行 级 别 探查 器 。 另 外 一 个 是 通过 包 dbms_hprof 进 行 管理 的 调用 级 别 探 
查 器 (也 称 为 分 层 探查 器 ，hierarchical profiler )。 表 3-2 汇 总 了 每 种 探查 器 的 主要 优势 。 


表 3-2 ”DBMS HPROF 和 DBMS_PROFILER 的 主要 优势 


DBMS_HPROF DBMS PROFILER 
开启 后 对 开销 影响 非常 小 提供 行 级 别 的 信息 
提供 调用 级 别 的 信息 11.1 版 本 之 前 就 可 以 使 用 
有 “selftime” 和 “total time” 的 概念 所 有 主要 开发 工具 都 支持 
并 不 需要 附加 的 权限 


支持 native-compiled PL/SQL 


分 层 探查 器 探查 器 提供 的 运行 时 统计 信息 不 仅 要 比 行 级 别 探查 器 更 精确 ， 同 时 也 更 有 用 。 除 非 你 
确实 需要 行 级 别 的 信息 。 因 此 ， 如 果 可 能 ， 建 议 使 用 分 层 探查 器 ， 除 非 你 有 特别 的 需求 ， 需 要 使 用 行 
级 别提 供 的 信息 。 


3.2.1 使 用 DMBS_HPROF 


借助 11.1 版 本 中 引入 的 包 dbms_hprof， 你 可 以 在 会 话 级 别 启用 和 禁用 分 层 探 查 器 。 启 用 之 后 ， 会 
为 执行 的 每 个 PL/SQL 和 SQL 调用 收集 以 下 信息 : 

口 调用 执行 的 总 次 数 ; 

口 处 理 调用 花费 的 时 间 ; 

口 处 理子 调用 花费 的 时 间 ; 

口 调用 层次 结构 信息 。 

用 户 在 会 话 级 别 可 以 执行 ( 有 一 个 限制 是 , 封装 的 PL/SQL 代 码 只 允许 你 收集 顶级 调用 的 信息 ) 的 
所 有 PL/SQL 代 码 ( 比如 在 包 和 触发 器 中 的 代码 ) 都 会 被 收集 。 你 只 需要 对 包 dbms_hprof 有 EXECUTE 权 
限 就 可 以 启用 探查 。 

探查 期 间 收集 到 的 数据 会 存储 到 操作 系统 级 别 上 的 某 个 跟踪 文件 中 。 然 后 ， 为 了 探查 目的 ， 可 以 
将 该 数据 像 图 3-4 所 示 的 那样 加 载 到 数据 库 表 中 ， 或 者 也 可 以 使 用 PLSHPROF 实 用 工具 对 其 进行 处 理 。 


RUNID 
RUN_TIMESTAMP 
TOTAL_ELAPSED T 


ed C1 SUBTREE_ELAPSED_TIME 
RUN_COMMENT HASI FUNCTION_ELAPSED _TIME 
CALLS 


FUNCTION_ELAPSED TIME 
CALLS 


图 3-4 ”探查 器 将 收集 到 的 信息 存储 到 三 个 数据 库 表 中 ， 请 注意 带 下 划 线 的 字段 为 主键 
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关于 已 探查 会 话 的 信息 会 保存 在 表 dbmshp_ runs 中 。 为 每 次 运行 执行 的 子 程序 列表 保存 在 表 
dbmshp_ function_info 中 。 调 用 方 与 被 调用 方 之 间 的 父子 关系 保存 在 表 dbmshp_parent_child_ info 中 。 
换 句 话说 ， 表 dbmshp_parent_child info 包 含 用 于 重 构 调 用 层次 结构 的 信息 。 


1. 创建 输出 表 

包 dbms_hprof 是 以 执行 它 的 用 户 的 权限 来 运行 的 。 因 此 , 输出 表 并 不 需要 由 sys 用 户 创建 。 要 么 由 
数据 库 管 理 员 安装 一 次 输出 表 ( 通过 运行 dbmshptab.sql 脚 本 )， 并 提供 使 用 这 些 表 的 必要 同义词 和 权 
限 ， 要 么 由 每 个 用 户 在 自己 的 schema 下 安装 。 在 下 面 这 个 例子 中 ， 由 数据 库 管理 员 安 装 一 次 输出 表 : 


CONNECT / AS SYSDBA 
@?/rdbms/admin/dbmshptab.sql 


CREATE PUBLIC SYNONYM dbmshp runs FOR dbmshp_runs; 

CREATE PUBLIC SYNONYM dbmshp function info FOR dbmshp function info; 

CREATE PUBLIC SYNONYM dbmshp parent child info FOR dbmshp parent child info; 
CREATE PUBLIC SYNONYM dbmshp runnumber FOR dbmshp_runnumber; 


GRANT SELECT, INSERT, UPDATE, DELETE ON dbmshp runs TO PUBLIC; 

GRANT SELECT, INSERT, UPDATE, DELETE ON dbmshp function info TO PUBLIC; 
GRANT SELECT, INSERT, UPDATE, DELETE ON dbmshp parent child info TO PUBLIC; 
GRANT SELECT ON dbmshp runnumber TO PUBLIC; 


2. 收集 探查 数据 

通过 调用 start_profiling 过 程 来 启用 探查 器 ， 开 始 探查 分 析 。 该 过 程 支 持 三 个 参数 

口 location: 指定 包含 探查 数据 的 跟踪 文件 的 存放 位 置 ， 需要 指定 操作 系统 级 别 的 目录 名 。 

口 filename: 指定 跟踪 文件 名 。 如 果 文 件 存在 ,- 会 直接 窗 盖 。 

口 max_depth: 指定 探查 数据 收集 是 否 受 到 指定 调用 深度 限制 。 默 认 情 况 下 (NULL ), 没有 限制 。 

启用 探查 器 之 后 , 会 收集 由 PL/SQL 引 擎 执行 的 代码 探查 数据 。 调用 stop_profiling 过 程 可 禁用 探查 。 

包含 探查 数据 的 跟踪 文件 可 用 之 后 ， 就 立即 可 以 通过 调用 analyze 函 数 将 跟踪 文件 加 载 到 输出 表 
中 。 调 用 analyze 函 数 需 要 指定 两 个 参数 : location 和 filename。 这 两 个 参数 的 作用 与 start_profiling 
过 程 中 的 同名 参数 一 模 一 样 。 因 此 ， 你 应 该 把 它们 设置 成 与 start_profiling 过 程 相同 的 值 。analyze 
函数 也 支持 其 他 参数 ， 你 可 以 在 PLMSOL Packages and Types Reference 手 册 中 查看 这 些 参数 。 

下 面 的 例子 引 自 脚 本 dbms_hprof.sql 生 成 的 输出 。 这 个 例子 为 了 探查 一 个 匿名 PL/SQL 块 而 做 了 一 
次 最 小 限度 的 执行 。 将 探查 器 数据 加 载 到 数据 库 中 时 所 选择 的 runid 值 会 在 下 一 部 分 对 探查 会 话 的 输 
出 进行 分 析 时 使 用 到 。 


SQL> BEGIN 
2 dbms_hprof.start profiling(location => 'PLSHPROF_DIR', 
3 filename => 'dbms_hprof.trc'); 
4 END; 
5 也 


SQL> DECLARE 
2 1 count INTEGER; 
3 BEGIN 
4 perfect triangles(1000); 
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5 SELECT count(*) INTO 1 count 
6 “FROM all objects; 

+ END:; 
8 7 


SQL> BEGIN 
2 dbms_hprof. stop profiling; 
3 END; 
4 7 


SQL> SELECT dbms hprof.analyze(location => 'PLSHPROF_ DIR', 
2 filename => 'dbms_ hprof.trc') AS runid 
3 FROM dual; 


一 旦 将 探查 数据 加 载 到 输出 表 中 , 就 该 生成 报表 了 。 下 面 几 节 会 介绍 用 来 生成 报表 的 三 种 主要 方法 。 


3. 手动 生成 探查 数据 报表 
如 本 节 所 示 , 将 探查 数据 存 入 输出 表 后 , 就 可 以 进行 正常 的 查询 。 下 面 的 例子 引 自 dbms_hprof.sql 
脚本 生成 的 输出 。 
第 一 个 查询 把 探查 数据 按照 命名 空间 进行 分 组 。 在 本 例 中 , 你 可 以 看 到 PL/SQL 代 码 占用 的 响应 时 
间 比 例 ( 这 里 是 45.1% )， 你 只 有 继续 在 探查 器 提供 的 数据 里 找到 更 多 的 细节 才能 找 出 这 代表 的 意义 。 
另 一 方面 ， 如 果 你 发 现 SQL 占 用 了 大 多 数 的 响应 时 间 , 那么 使 用 PL/SQL 探 查 器 就 是 错误 的 ; 你 可 以 使 
用 SQL 跟踪 等 更 好 的 工具 来 找 出 哪些 SQL 运行 缓慢 。 不 管 哪 种 方式 ， 第 一 个 查询 提供 了 有 用 的 信息 ， 
它 能 帮助 你 了 解 接 下 来 需要 关注 哪些 地 方 。 
下 面 是 第 一 个 查询 输出 的 例子 : 
SOL> SELECT sum(function elapsed time)/1000 AS total ms, 
2 100*ratio to report(sum(function elapsed time)) over () AS total percent, 
3 sum(calls) AS calls, 
4 100*ratio to report(sum(calls)) over () AS calls percent, 
5 namespace AS namespace name 
6 FROM dbmshp function info 
7 WHERE runid = 1 
8 
9 


GROUP BY namespace 
ORDER BY total ms DESC; 


TOTAL [ms] TOT% CALLS CAL% NAMESPACE NAME 
565 54.9 89 5.6 SQL 
464 45.1 1,494 94.4 PLSQL 


第 二 个 查询 与 第 一 个 查询 很 像 ， 它 把 探查 数据 按照 模块 级 别 分 组 。 在 这 里 ， 可 以 看 到 
perfect triangles 过 程 占用 了 PL/SQL 的 大 部 分 响应 时 间 ( 44.9% )。 


SQL> SELECT sum(function elapsed time)/1000 AS total ms, 
2 100*ratio to report(sum(function elapsed time)) over () AS total percent, 
sum(calls) AS calls, 
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4 100*ratio to report(sum(calls)) over () AS calls percent, 
5 namespace, 
6 nvl(nullif(owner || '." || module, '.'), function) AS module name, 
type 
8 FROM dbmshp function info 
9 WHERE runid = 1 
10 GROUP BY namespace, nvl(nullif(owner || '.' || module, '.'), function), type 
11 ORDER BY total ms DESC; 
TOTAL [ms] TOT% CALLS CAL% NAMESPACE MODULE_ NAME TYPE 
521 50.6 4 外 SOL _ Static sql exec line5 
462 44.9 1,214 76.7 PLSQL CHRIS.PERFECT TRIANGLES PROCEDURE 
44 4.3 88 5.6 SQL SYS.XML SCHEMA NAME PRESENT PACKAGE BODY 
| 44 2.8 PLSQL SYS.XML SCHEMA NAME PRESENT PACKAGE BODY 
04 3 2 PELSQL _ plsql_vm 
0] 3 SQL __anonymous_ block 
0 0.0 46 2.9 PLSQL _plsql vm@1 
0 ‘00 179, 3 PLSQU SYS.DBMS OUTPUT PACKAGE BODY 
0 0.0 1 01 PLSOL SYS.DBMS UTILITY PACKAGE BODY 
0 0.0 1 vt PLSOL SYS.DBMS SESSION PACKAGE BODY 
0 0.0 4 WuL PLSQL SYS.DBMS APPLICATION INFO PACKAGE BODY 
0 00 1 ‘01 PLSQL SYS.DBMS APPLICATION INFO PACKAGE SPEC 
0 00 1 0 LS SYS.DBMS HPROF PACKAGE BODY 


第 三 个 查询 的 目的 是 分 层 并 在 一 个 更 好 的 级 别 进行 分 组 ( 包括 所 有 的 PL/SQL 调 用 )， 它 并 不 只 是 
简单 地 显示 调用 分 层 ， 同 时 也 会 显示 调用 方 和 被 调用 方 花费 的 时 间 。 例 如 ， 你 可 以 看 到 调用 
perfect triangles 花 费 了 463 毫 秒 ， 该 过 程 本 身 花 费 了 393 毫 秒 。 被 调用 方 sides_are_unique 和 


store_ dup_sides 占 用 了 剩 下 的 69 毫 秒 (64+5 )， 它 们 并 没有 出 现在 之 前 的 查询 中 。 


SQL> SELECT lpad(' ', (level-1) * 2) || nullif(c.owner || '.', '.') || 
2 CASE WHEN c.module = c.function 
3 THEN c.function 
4 ELSE nullif(c.module || '.', '.') || c.function END AS function name, 
5 pc.subtree elapsed time/1000 AS total ms, 
6 pc.function elapsed time/1000 AS function ms, 
7 pc.calls AS calls 
8 FROM dbmshp parent child info pc， 
9 dbmshp_ function info p， 
10 dbmshp_function info c 


11 START WITH pc.runid = 1 

12 AND p.runid = pc.runid 

13 AND c.runid = pc.runid 

14 AND pc.childsymid = c.symbolid 

15 AND pc.parentsymid = p.symbolid 

16 AND p.symbolid = 1 

17 CONNECT BY pc.runid = prior pc.runid 
18 AND p.runid = pc.runid 

19 AND c.runid = pc.runid 

20 AND pc.childsymid = c.symbolid 

21 AND pc.parentsymid = p.symbolid 

22 AND prior pc.childsymid = pc.parentsymid 
23 ORDER SIBLINGS BY total ms DESC; 
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FUNCTION NAME TOTAL [ms] FUNCTION [ms] CALLS 
_ Static sql exec line5s 566 521 和 
_ pl1sql_vm@1 45 0 46 
SYS.XML SCHEMA NAME PRESENT.IS SCHEMA PRESENT 45 1 44 
SYS.XML SCHEMA NAME PRESENT. dyn_ sql exec line34 22 22 44 
SYS.XML SCHEMA NAME PRESENT. dyn sql exec line17 22 22 44 
CHRIS.PERFECT TRIANGLES 463 393 1 
CHRIS.PERFECT_TRIANGLES.PERFECT TRIANGLES.SIDES ARE UNIOQUE 64 64 1,034 
CHRIS.PERFECT TRIANGLES.PERFECT _ TRIANGLES.STORE DUP_SIDES 5 5 179 
SYS.DBMS OUTPUT.PUT_ LINE 0 0 179 
SYS.DBMS SESSION.IS ROLE ENABLED 0 0 1 
SYS.DBMS. UTILITY .CANONICALIZE 0 0 1 
SYS.DBMS APPLICATION INFO.SET MODULE 0 0 半 
SYS.DBMS APPLICATION INFO. pkg init 0 0 at 
SYS.DBMS HPROF .STOP_PROFILING 0 0 


4. 使 用 PLSHPROF 

可 以 使 用 命令 行 工具 PLSHPROF 来 处 理由 dbms_hprof 生 成 的 跟踪 文件 。 在 工具 执行 期 间 会 生成 一 
些 HTMP 报 告 。 如 果 不 加 任何 参数 执行 PLSHPROF， 那 么 返回 的 是 PLSHPROF 的 完整 参数 列表 ， 以 及 
各 参数 的 简短 描述 。 2 


Usage: plshprof [<option>...] <tracefile1> [<tracefile2>] 


Options: 
-trace <symbol> (no default) specify function name of tree root 
-Skip <count> (default=0) skip first <count> invokations 
-collect “count> (default=1) collect info for <count> invokations 
-output “filename> (default=<symbol>.html or <tracefile1>.html) 
-Summary print time only 
如 你 所 见 ， 可 以 指定 一 个 或 两 个 跟踪 文件 和 多 个 选项 。 如 果 只 指定 了 单独 的 一 个 跟踪 文件 ， 
PLSHPROF 会 生成 如 下 报告 : 


口 根据 8 个 不 同 的 条 件 进 行 分 类 的 函数 已 用 时 间 数 据 ; 

口 根据 3 个 不 同 的 条 件 进 行 分 类 的 模块 已 用 时 间 数 据 ; 

口 根据 3 个 不 同 的 条 件 进 行 分 类 的 命名 空间 已 用 时 间 数 据 ; 

口 父 级 别 与 子 级 别 的 已 用 时 间 数 据 。 

例如 ， 以 下 命令 处 理 跟踪 文件 doms_hprof.trc 并 且 生 成 包含 一 组 报告 的 文件 dbms_hprof.html: 

plshprof -output dbms hprof dbms hprof.trc 

请 注意 ， 跟 踪 文 件 和 HTML 报 告 都 可 以 在 dbms_hprof.zip 中 找到 。 图 3-5 显 示 了 其 中 一 个 报告 。 

当 你 想 对 比 同 一 个 程序 里 的 两 个 运行 结果 时 ， 可 以 指定 两 个 跟踪 文件 。 例 如 ， 可 以 指定 两 个 跟 
踪 文 件 并 且 对 比 代 码 的 改变 对 性 能 产生 的 影响 。 如 果 这 两 个 跟踪 文件 不 相同 ， 那 么 PLSHPROF 会 生 
成 一 个 报表 集合 ， 这 些 报表 与 为 单个 跟踪 文件 生成 的 报表 相似 ， 但 PLSHPROF 会 标明 两 次 运行 之 间 
的 增 量 。 
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acaule| rnds | cums [callas| Ind%| 
[522033|[50.7 |50.7%| 53]| 3.39 
[462495 
| | 4 


I 


44. Ee EE CHRIS.PERFECT TRIANGLES | 
3%| 100%| 132| 8.3%|SYS.XML SCHEMA NAME PRESENT| 
一 
[ 23 0.0%| 100%[ 2 0.1% SYS.DBMS_APPLICATION INFO | 
[5 22[o.0o%[ 100%[ 1[o.1%SYs.DBMs UTILITY | 
i 


图 3-5 ”由 PLSHPROF 生 成 并 按 总 函数 已 用 时 间 排 序 的 模块 已 用 时 间 数 据 


EE 
ES 
oO 
Oo 
Ww 


5. 使 用 图 形 界面 

除了 前 面 提 到 的 方法 外 ， 也 可 以 使 用 第 三 方 带 有 图 形 界面 的 产品 。 比 如 SQL Developer ( Oracle ) 
和 Toad ( Dell ), 通常 情况 下 ,这 些 丁 具 通 过 勾 选 复 选 框 或 单 击 按钮 ,或 者 直接 分 析 输 出 表 内 容 就 可 以 
探查 代码 了 。 

图 3-6 至 图 3-8 显 示 了 SQL Developer 为 在 前 几 部 分 中 冰 述 的 探查 会 话 提供 的 部 分 信息 。 


[ea hs 30.2% 1494 94.4% PLSOL 
|992989 hs 69.8% 89 5.6% SOL 


图 3-6 ”SQL Developer 中 显示 的 命名 空间 级 别 的 探查 数据 


462495 hs 44.98 1214 76.7% CHRIS.PERFECT TRIANGLES 
144683 hs 4.38% 132 8.3% SYS.XML SCHEMA NAME PRESENT 
|25 hs 0.0% 179 11.3% SYS.DBMS OUTPUT 

|23 hs 0.0% 2 0.1% SYS.DBMS APPLICATION INFO 
|22 hs 0.0% 1 0.1% SYS.DBMS UTILITY 

|21 hs 0.0% 1 0.1% SYS.DBMS SESSION 

lo hs 0.09 1 0.1% SYS.DBMS HPROF 


图 3-7 ”SQL Developer 中 显示 的 模块 级 别 的 探查 数据 
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Function Calls | Module 4 Namespace | Call Hierardhy 


393062 hs 462520 


CHRIS.PERFECT TRIANGLES.PERFECT TRIANGLES.SIDES ARE UNIQUE 64279 hs 64279 1034 
CHRIS.PERFECT TRIANGLES.PERFECT TRIANGLES.SIORE DUP SIDES 5154 hs 5154 179 
SYS.DBMS _ OUTPUT.PUT LINE 25 hs 25 179 
|ISYS ,DBMS_APPLICRTION_INFO.SET_MODULE 20 bs 20 1 
|SYS.DBMS APPLICATION INFO._pkg_init 3 hs 3 1 
SYS .DBMS_ HPROF.STOP PROFILING 0 hs 0 1 
ISYS .DBMS_SESSION.IS_ ROLE_ENABLED 21 hs 43 1 
SYS.DBMS UTILITY.CANONICALIZE 22 hs 22 1 
.static sql exec lineS 520995 Ps 565797 1 
-._Plsql vmel1 119 bs 44802 46 
SYS. XML SCHEMA NAME PRESENT.IS SCHEMA_ PRESENT 750 ps 44683 44 

SYS5.XML SCHEMA NAME PRESENT. dyn sql exec linel7 21855 hs 21855 44 

SYS.XML_ SCHEMA NAME PRESENT._ dyn sql exec line34 22078 hs 22078 44 


图 3-8 SQL Developer 中 显示 的 调用 层次 结构 的 探查 数据 


3.2.2 使 用 DBMS_PROFILER 


使 用 包 dbms_profiler 可 以 在 会 话 级 别 启用 和 禁用 行 级 别 探查 器 。 启 用 探查 器 之 后 , 针对 每 行 执行 
过 的 代码 ， 会 收集 如 下 信息 : 

口 总 执行 次 数 ; 

口 执行 时 的 总 花费 时 间 ; 

口 执行 时 花费 的 最 短 时 间 和 最 长 时 间 。 

只 要 用 户 拥有 CREATE 权 限 , 那么 他 在 会 话 级 别 执行 的 所 有 PL/SQL 代 码 都 会 被 收集 , 但 不 包括 封装 

和 本 地 编译 的 代码 。 换 句 话 说， 拥有 执行 一 段 PL/SQL 代 码 的 权限 并 不 足以 使 用 探查 器 。 因 此 ， 实 际 上 
只 有 被 探查 对 象 的 所 有 者 或 拥有 CREATE ANY 权 限 的 用 户 才能 进行 探查 。 

图 3-9 显 示 了 探查 数据 存储 在 数据 库 中 的 表 结 构 。 探 查分 析 的 信息 存在 表 plsql_profiler_runs 中 。 
每 次 执行 的 单位 列表 保存 在 表 plsql profiler units 中。 每 行 代码 执行 后 的 探查 数据 保存 在 表 
plsql profiler data 中 。 


UNIT NUMBER 


LINE# 
TOTAL_OCCUR 


| TOTAL TIME 


RUNID 
RELATED_RUN 


RUN_COMMENT | 
RUN_TOTAL_TIME UNIT_ TIMESTAMP 
RUN_SYSTEM _INFO TOTAL_TIME 
RUN_COMMENT1 SPARE1 

SPARE1 SPARE2 


图 3-9 ”探查 器 将 收集 到 的 信息 存储 在 三 个 数据 库 表 中 ,请 注意 ， 带 下 划 线 的 字段 为 主键 
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1. 安装 输出 表 

包 是 以 执行 它 的 用 户 的 权限 运行 的 。 因 此 ， 输 出 表 并 不 需要 由 sys 用 户 来 创建 。 要 么 由 数据 库 管 
理 员 来 安装 一 次 输出 表 ( 通过 运行 dbmshptab.sql 脚 本 ), 并 提供 使 用 这 些 输出 表 的 必要 同义词 和 权限 ， 
要 么 由 每 个 用 户 在 自己 的 schema 下 安装 输出 表 。 


CONNECT / AS SYSDBA 
@?/rdbms/admin/proftab.sql 


CREATE PUBLIC SYNONYM plsql profiler runs FOR plsql profiler runs; 

CREATE PUBLIC SYNONYM plsql profiler units FOR plsql profiler units; 

CREATE PUBLIC SYNONYM plsql profiler data FOR plsql profiler data; 

CREATE PUBLIC SYNONYM plsql profiler runnumber FOR plsql profiler runnumber; 


GRANT SELECT, INSERT, UPDATE, DELETE ON plsql profiler runs TO PUBLIC; 
GRANT SELECT, INSERT, UPDATE, DELETE ON plsql profiler units TO PUBLIC; 
GRANT SELECT, INSERT, UPDATE, DELETE ON plsql profiler data TO PUBLIC; 
GRANT SELECT ON plsql profiler runnumber TO PUBLIC; 


2. 收集 探查 数据 

通过 调用 例 程 start_profiler， 可 以 在 启用 探查 器 的 情况 下 开始 探查 分 析 。 启 用 探查 需 之 后 ， 会 
为 PL/SQL 引 警 所 执行 的 代码 收集 探查 数据 。 除 非 通过 调用 flush_data 例 程 执行 显 式 刷新 ， 和 否则 虽然 启 
用 了 探查 器 , 也 不 会 将 任何 探查 数据 存储 到 输出 表 中 。 通过 调用 stop_profiler 例 程 , 可 以 禁用 探查 器 ， 
并 执行 隐 式 刷新 。 此 外 ， 通 过 调用 pause_profiler 和 resume_profiler 例 程 ， 可 以 分 别 暂停 和 恢复 探查 
器 。 图 3-10 显 示 了 探查 器 的 状态 以 及 dbms_profiler 中 可 用 于 触发 状态 更 改 的 例 程 。 


flush_data 


stop_profiler 


图 3-10 ”探查 器 状态 图 。 包 dbms_profiler 提 供用 于 更 改 探 查 器 状态 ( 禁用、 启用 或 
暂停 ) 的 例 程 


针对 图 3-10 中 的 每 一 个 例 程 ， 包 dbms_profiler 都 有 对 应 的 函数 和 过 程 。 函 数 会 返回 执行 结果 ( 0= 
成 功 )。 在 出 错时 会 抛 出 异常 。 除 了 例 程 start_profiler 需 要 使 用 描述 探查 分 析 的 两 个 注释 作为 参数 ， 
其 他 例 程 都 是 无 参数 的 。 
下 面 的 例子 引 自 脚本 dbms_profiler.sql 生 成 的 输出 。 请 注意 ， 禁 用 探查 器 时 所 选择 的 runid 值 会 
在 下 一 部 分 引用 在 输出 表 中 储存 的 探查 数据 时 使 用 到 。 
SQL> SELECT dbms profiler.start profiler AS status 
2 FROM dual; 


STATUS 
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0 
SOL> execute perfect triangles(1000) 


SQL> SELECT dbms profiler,.stop profiler AS status, 
2 plsql profiler runnumber.currval AS runid 
3 FROM dual; 


STATUS RUNID 


探查 会 话 一 结束 , 就 应 该 报告 由 探查 器 生成 的 数据 。 接 下 来 的 两 部 分 会 介绍 两 种 主要 的 报告 方法 。 


3. 手工 报告 探查 数据 

由 于 探查 数据 保存 在 输出 表 中 ， 所 以 可 以 通过 正常 查询 来 获取 数据 。 以 下 是 由 脚本 
dbms_profiler.sql 生 成 的 输出 。 查 询 结果 出 于 两 个 原因 只 提供 了 响应 时 间 的 百分比 : 首先 ,我们 通常 
只 关心 代码 最 慢 的 部 分 ; 其 次 ， 定 时 信息 ， 尤 其 当代 码 是 CPU bound 时 ， 非 常 不 可 靠 。 实 际 上 ， 对 于 
CPU-bound 处 理 ， 探 查 器 会 造成 很 高 的 开销 。 在 本 例 里 ， 就 是 CPU bound， 处 理 时 间 从 不 到 1 秒 增加 到 
7 秒 左 右 。 而 在 这 7 秒 中 ， 只 有 大 约 4 秒 会 为 探查 器 所 用 。 


Ea 


SQL> SELECT s.line, 
round(ratio to report(p.total time) OVER ()*100,1) AS time, 


Ld 


3 total occur, 

4 Ss.text 

5 FROM all source s, 

6 (SELECT u.unit owner, Uu.unit name, u.unit type, 

7 d.line#, d.total time, d.total occur 

8 FROM plsql profiler units u, plsql profiler data d 
9 WHERE u.runid = 1 

10 AND d.runid = u.runid 

11 AND d.unit number = u.unit number) p 


12 WHERE s.owner = p.unit owner (+) 


13 AND s.name = p.unit name (+) 

14 AND s.type = p.unit type (+) 

15 AND s.line = p.line# (+) 

16 AND s.owner = USeT 

17 AND s.name = 'PERFECT_TRIANGLES' 

18 AND s.type IN ('PROCEDURE', "PACKAGE BODY', 'TYPE BODY') 

19 ORDER BY s.line; 

LINE# TIME% EXEC# CODE 

1 0.0 1 PROCEDURE perfect triangles(p max IN INTEGER) IS 

29 17:7 1;105;,793 FOR j IN 1..n 
30 LOOP 
31 22.3 1,105,614 IF p long = dup sides(j).long 
32 AND 
33 p_short = dup sides(j).short 
34 THEN 


35 0.0 855 RETURN FALSE; 
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36 END IF; 

37 END LOOP; 

44 8.2 501, 500 FOR short IN 1..1long 

45 LOOP 

46 21.4 500, 500 hyp := sqrt(long*long + short*short); 
47 0 500, 500 ihyp := floor(hyp); 

48 1055 500, 500 IF hyp-ihyp“ 0.01 

49 THEN 

50 0.2 10,325 IF ihyp*ihyp = long*long + short*short 
5 THEN 

52 0.1 1,034 IF sides are unique(long, short) 
53 THEN 

54 0.0 179 m := m+1; 

55 0.0 179 unique sides(m).long := long; 
56 0.0 179 unique sides(m).short := short; 
57 0.0 179 store dup sides(long, short); 
58 END IF; 

59 END IF; 

60 END IF:; 

61 END LOOP; 

69 0.0 1 END perfect triangles; 


Oracle 针 对 探查 数据 提供 了 两 组 脚本 以 及 查询 示例 。 

口 如 果 安 装 了 示例 文件 ( 默认 情况 下 不 安装 ), 那么 在 $ORACLE_HOMEXplsql/demo/ 目 录 下 会 存在 脚 
本 profrep.sql。 

口 参见 Oracle Support 文 档 Script to produce HTML report with top consumers out of PLMSOL Profiler 
DBMS_ PROFILER data (243755.1 )。 


4. 使 用 图 形 界 面 

上 面 介 绍 的 手工 方法 也 可 以 使 用 第 三 方 工具 图 形 界面 来 实现 ， 比 如 PL/SQL Developer ( Allround 
Automations )、 SQLDetective ( Conquest Software Solutions )、 Toad 和 SQL Navigator ( Dell ) 或 者 Rapid Sql 
( Embarcadero )。 通 常 ， 通 过 在 运行 测试 之 前 勾 选 复 选 框 或 单 击 按钮 ， 或 者 通过 直接 分 析 输 出 表 内 容 ， 
所 有 这 些 工具 都 可 以 用 于 探查 代码 。 

例如 , 图 3-11 显 示 了 SQL Developer 为 前 几 部 分 中 阐述 的 探查 会 话 提供 的 信息 。 请 注意 “Total time” 
列 中 的 图 示 ， 该 图 示 高 亮 显 示 了 主要 的 耗 时 代码 行 。 
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1105793 FORJIN 1.n 
-1056141 IF p_long = dup_ sides(). long 
855， RETURN FALSE: 
179 RETURN TRUE: 
1034| IEND sides_are_unique: 
1001 FOR long IN 1.p_max 
501500 FOR: shortIN 1.long 
500500|| hyp = sqrt(long"long- + shorF'shord): 
500500 ihyp = floor(hyp); 

500500 IF hyp-ihyp < 0.01 | 
| 10325IF ihyp"ihyp = :long*long- + shor'short 
1034 IF sides_are_unique(long, short) 

179 m := m+1: 

179| unique_sides(m).Iong =long: 
179 unique_sides(m).shor := short. 
179 store_dup _sides(long. short): 


46 


| 


BE EE 


图 3-11 ”PL/SQL Developer 中 显示 的 探查 数据 


3.2.3 ”触发 探查 器 


仅 可 以 从 执行 要 探查 的 PL/SQL 代 码 的 会 话 内 启用 和 禁用 这 两 个 探查 器 。 如 果 探查 无 法 手动 启动 ， 
也 可 以 像 下面 这 样 通过 创建 数据 库 触 发 器 来 为 整个 会 话 自 动 启用 和 禁用 探查 器 : 


CREATE TRIGGER start hprof profiler AFTER LOGON ON DATABASE 
BEGIN 
IF (dbms session.is role enabled('HPROF PROFILE')) 
THEN 
dbms_hprof.start profiling( 
location => 'PLSHPROF DIR', 
filename => 'dbms hprof '||sys_context('userenv','sessionid’)||'.trc’ 


CREATE TRIGGER stop hprof profiler BEFORE LOGOFF ON DATABASE 
BEGIN 

IF (dbms_ session.is role enabled('HPROF PROFILE')) 

THEN 

dbms_hprof. stop profiling(); 

END IF; 
END; 
/ 
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以 上 触发 器 针对 的 是 分 层 探 查 器 。 可 以 在 脚本 dbms_hprof triggers.sql 和 dbms_profiler triggers. 
sql 中 找到 用 于 为 这 两 个 探查 器 创建 触发 器 的 代码 。 如 上 面 的 触发 器 所 示 ， 为 了 避免 为 所 有 用 户 启用 
探查 器 ， 我 通常 建议 创建 一 个 角色 ( 本 例 为 hprof_profile ) 并 且 仅 向 测试 需要 的 用 户 临 时 赋予 权限 ， 
当然 ， 可 以 只 为 某 个 单独 的 架构 定义 触发 器 或 者 设置 其 他 限制 条 件 ， 比 如 基于 环境 变量 userenv。 


33 ， 小结 


本 章 详 细 介 绍 了 Oracle 数 据 库 为 识别 可 重 现 的 性 能 问题 而 提供 的 跟踪 和 探查 功能 。 特 别 介绍 了 
SQL 跟 踪 及 其 相关 工具 ,以 及 两 个 通过 包 dbms_hprof 和 dbms_profiler 而 具体 化 了 的 PL/SQL 探 查 器 。 借 
助 这 些 工具 ， 当 你 尝试 诊断 由 SQL 语句 或 PL/SQL 代 码 引 起 的 性 能 下 降 时 ， 就 不 会 感到 手忙脚乱 。 

当 你 无 法 重 现 问 题 ， 或 者 在 问题 发 生 时 才 不 得 不 分 析 它 时 ,本 章 介 绍 的 方法 在 大 多 数 时 候 是 没 用 
的 。 对 于 这 些 情形 ， 你 可 以 应 用 接 下 来 在 第 4 章 中 介绍 的 功能 。 


实时 分 析 不 可 重 现 的 人 


实时 分 析 性 能 问题 可 以 从 动态 性 能 视图 中 获取 关键 信息 。 在 众多 视图 中 ， 找 到 正确 的 视图 并 用 合 
适 的 排序 来 查询 ， 是 有 效 确 定性 能 问题 的 关键 。 为 了 能 找到 正确 的 动态 性 能 视图 ， 你 需要 考虑 下 面 这 
个 关键 问题 : 

我 能 使 用 Diagnostics Pack 和 Tuning Pack 选 件 吗 ? 

这 个 问题 根本 就 不 是 技术 问题 。 然 而 回答 这 个 问题 是 很 必要 的 ， 因 为 只 有 在 你 有 对 应 的 许可 时 ， 
才 可 以 使 用 某 些 动态 性 能 视图 和 数据 库 特 性 ( 实时 分 析 的 关键 特性 是 活动 会 话 历史 和 实时 监控 )。 请 
注意 ，Diagnostics Pack 选 件 是 Tuning Pack 选 件 的 先决 条 件 。 同 时 所 有 的 选 件 只 在 企业 版 中 可 用 ， 标 准 
版 并 不 支持 。 有 关 许 可 的 详细 信息 ， 请 参考 Oracle Database Licensing Information 手 册 。 


提示 “如 果 没 有 Diagnostics Pack 选 件 和 Tuning Pack 选 件 的 许可 ,从 11.1 版 本 开始 可 以 设置 相应 的 初始 
化 参数 control management pack access。 企 业 版 的 默认 值 是 diagnostic+tuning。 这 代表 两 个 
选 件 都 被 启用 。 其 他 可 用 的 值 有 diagnostic 和 none。 前 者 仅仅 启用 Diagnostics Pack 选 件 ， 而 后 
者 禁用 两 个 选 件 ， 并 且 这 也 是 标准 版 的 默认 值 。 为 这 个 初始 化 参数 设置 合适 的 值 有 两 个 好 处 。 
第 一 ， 禁 止 一 些 特性 可 以 防止 不 必要 的 开销 ,第 二 ， 当 使 用 Enterprise Manager 时 ,这 两 个 选 件 
对 应 的 页 面 会 无 法 打开 ， 这 样 就 不 会 违反 许可 协议 


分 析 的 步骤 与 能 和 否 使 用 这 些 可 选 特性 无 关 。 让 我 们 用 一 张 分 析 路 线 图 来 讨论 一 下 。 


4.1 分 析 路 线 图 


图 4-1 显 示 了 性 能 分 析 所 需要 的 步 又。 首先 , 你 需要 检查 数据 库 服务 器 的 负载 情况 , 特别 是 执行 两 
个 检查 。 第 一 ， 确 定数 据 库 服务 器 是 否 是 CPU bound。 如 果 是 ,那么 许多 统计 信息 会 被 人 为 地 扩大 。 
因此 ， 首 要 目标 是 要 找 出 一 种 方法 来 减 小 CPU 使 用 率 。 第 二 ， 检 查 消耗 大 量 CPU 的 进程 是 否 与 数据 库 
实例 无 关 。 如 果 是 的 话 ， 那 么 无 法 找到 引起 性 能 问题 的 原因 可 能 是 你 的 关注 点 错 了 。 

检查 了 数据 库 服 务 器 负载 后 ， 你 有 三 个 选择 。 你 需要 问 自己 下 面 这 个 问题 来 决定 选择 哪个 : 

我 的 目标 是 什么 ”是 单条 SQL 语 句 、 单 个 会 话 还 是 整个 系统 ? 

你 可 以 有 针对 性 地 处 理 正在 经 历 性 能 问题 的 某 条 SQL 语 句 或 会 话 。 实 际 上 ， 正 如 第 1 章 所 述 ， 你 
应 该 尽 可 能 关注 具体 的 问题 。 然 而， 当 获 取 不 到 关键 信息 时 , 你 需要 继续 在 系统 级 别 进行 分 析 。 例如 ， 
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当 发 生生 产 环境 运行 缓慢 并 且 原 因 未 知 时 ， 你 的 目标 不 再 是 处 理 某 个 业务 的 性 能 问题 ( 当然 ， 这 始终 
是 你 努力 的 方向 )， 而 是 想 办 法 降低 系统 的 负载 。 


检查 数据 库 
服务 器 负载 


否 或 为 空 


获取 二 条 或 多 条 
SQL 语句 的 信息 


根据 其 他 维度 
对 数据 进行 分 析 


检查 实用 SQL 优化 检查 应 用 
图 4-1 实时 分 析 不 可 重 现 问 题 的 路 线 图 


如 果 你 继续 在 系统 或 会 话 层面 分 析 ， 你 的 目标 应 该 是 找 出 是 否 有 一 小 部 分 SQL 语句 ( 比如 12 个 ) 
造成 了 大 量 的 负载 。 例 如 ， 你 发 现 85% 的 负载 是 由 7 条 SQL 语句 造成 的 ， 应 该 能 很 清楚 地 定位 负载 较 
多 的 SQL。 然 而 ， 如 果 排 名 前 10 位 的 SQL 语句 只 占用 了 25% 的 负载 ,那么 它们 就 不 值得 你 浪费 时 间 去 
关注 。 

你 同样 应 该 检查 是 否 有 一 小 部 分 “组 件 ”( 比如 ， 会话、 模块 或 者 客户 端 ) 占用 了 大 量 的 负载 
如 果 是 ， 应 该 仅 针对 “组 件 ” 进 行 分 析 。 总 之 ， 如 果 系统 层面 的 分 析 并 没有 找 出 占用 负载 较 多 的 SQL 
语句 ， 你 应 该 考虑 检查 应 用 是 否 在 有 效 运行 。 如 果 应 用 代码 无 法 进行 分 析 (或 者 修改 )， 或 者 检查 后 
并 没有 令 人 满意 的 结果 ,那么 你 能 考虑 的 就 只 剩 下 资源 管理 了 。 简 单 来 说 ， 你 有 两 个 选择 : 第 一 ， 明 
确 应 用 的 哪些 部 分 〈 比如 ,一些 会 话 或 用 户 ) 使 用 了 比 其 他 部 分 更 多 的 资源 ; 第 二 ， 给 应 用 更 多 的 资 
源 (比如 硬件 )。 当 然后 者 应 该 是 你 最 后 才 会 去 考虑 的 。 

思考 这 样 一 个 特别 的 案例 ， 你 分 析 的 系统 或 会 话 几乎 是 空闲 的 。 这 里 的 空闲 ， 是 指 大 部 分 处 理 时 
间 都 不 是 花费 在 数据 库 系统 里 。 例 如 ， 你 看 到 一 个 报表 运行 了 13 分 钟 ， 但 数据 库 引 擎 只 伦 了 42 秒 来 处 
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理 相 关 SQL 诸 句 ， 当 然 这 与 处 理 了 多 少 条 SQL 语句 无 关 ， 这 时 关注 数据 库 层 是 没 用 的 。 很 明显 ， 瓶 颈 
并 不 在 数据 库 层 。 这 时 也 需要 检查 程序 或 其 他 支撑 程序 的 部 分 。 

针对 你 找到 的 每 条 占用 负载 较 多 的 SQL 语句 ， 都 需要 收集 执行 计划 、 关 键 运行 时 统计 〈 比如 已 处 
理 的 行 数 和 CPU 使 用 率 的 数量 ) 以 及 已 经 历 的 等 竺 事件， 这 与 你 关注 的 是 单独 的 SQL 语句 、 单 个 会 话 
还 是 整个 系统 无 关 。 下 一 节 将 介绍 如 何 找 出 你 需要 知道 的 重要 动态 性 能 视图 的 基本 信息 。 然 后 本 章 将 
详细 解释 如 何 使 用 动态 性 能 视图 提供 的 信息 来 实时 分 析 性 能 问题 。 


4.2 动态 性 能 视图 


Oracle 数 据 库 利用 动态 性 能 视图 来 展现 一 些 属于 内 存 或 数据 库 文件 的 数据 结构 内 容 。 换 句 话说 ， 
即使 它们 看 起 来 像 普 通 的 表 ， 基 础 结构 保存 的 数据 却 完全 不 同 。 这 些 结构 以 视图 的 形式 展现 出 来 , 方 
便 用 户 使 用 SQL 语句 获取 数据 。 

数据 库 引 擎 时 常会 修改 动态 性 能 视图 依赖 的 数据 结构 ， 因 此 动态 性 能 视图 提供 的 数据 也 是 实时 变 
化 的 。 请 注意 并 不 是 每 个 动态 性 能 视图 都 以 同样 的 方式 更 新 。 例 如 ， 其 中 一 些 视 图 持续 更 新 ， 而 其 他 
的 视图 每 5 秒 才 更 新 一 次 。 


警告 ”查询 动态 性 能 视图 并 不 能 保证 一 致 读 。 因 忠 ， 不 要 让 小 错误 或 不 一 臻 影响 你 。 


我 通常 会 引用 v$ 前 级 的 视图 来 介绍 动态 性 能 视图 。 如 果 你 使 用 的 是 RAC 环 境 ， 请 注意 ，v$ 视 图 只 
会 显示 你 当前 连接 实例 的 信息 。 如 果 需 要 其 他 实例 的 信息 , 你 需要 使 用 带 gv$ 前 级 的 全 局 视图 。gv$ 视 图 
的 结构 与 v$ 视 图 相同 ,通常 情况 下 , 唯一 不 同 的 是 gv$ 视 图 会 多 出 一 列 ( inst_id ) 用 来 标识 数据 库 实例 。 

一 些 动 态 性 能 视图 提供 的 统计 信息 依赖 于 初始 化 参数 timed_statistics， 这 个 参数 可 以 设置 成 
TRUE 或 FALSE。 如 果 设 置 成 TRUE ， 计 时 信息 生效 。 如 果 设 置 成 FALSE， 则 看 不 到 这 些 统计 信息 。 然 而 ， 
根据 你 工作 的 平台 不 同 , 这 些 信息 也 可 能 存在 。timed_statistics 的 默认 值 跟 男 一 个 初始 化 参数 有 关 : 
statistics level。 如 果 将 statistics level 设 置 成 basic， 那 么 timed statistics 的 默认 值 为 FLASE， 
否则 其 默认 值 为 TRUE。 由 于 这 两 个 参数 的 默认 值 已 经 很 适合 ， 因 此 不 建议 在 系统 级 别 更 改 它们 。 

数据 库 里 存在 许多 动态 性 能 视图 。 下 面 介 绍 一 些 处 理性 能 问题 时 经 常会 用 到 的 视图 。 


4.2.1 操作 系统 统计 信息 


如 果 你 无 法 访问 数据 库 服 务 器 ， 但 又 想得到 一 些 操作 系统 级 别 的 核心 性 能 指标 ( 如 CPU 和 内 存 使 
用 率 ), 你 可 以 查询 v$osstat 获 取 你 想 要 的 信息 。 并 且 多 亏 了 comments 列 ,你 可 以 很 清晰 地 知道 每 行 值 
的 含义 ,请 注意 有 些 列 的 值 是 从 数据 库 实例 启动 时 开始 累积 的 ( 比如 , 所 有 提供 计时 信息 的 统计 信息 )， 
其 他 则 是 常量 ( 比如 ，socket 数 、CPU 数 和 CPU 核 数 ) 或 者 是 当前 值 ( 比如 ， 空 闲 内 存 的 总 量 )。 同 时 
要 注意 ， 根 据 数据 库 版 本 和 平台 的 不 同 ， 视 图 的 实际 内 容 也 会 不 同 。 下 面 的 例子 是 在 Linux 平 台 上 针 
对 12.1 版 本 执行 的 查询 : 

SQL> SELECT stat name, value, comments 

2 FROM v$osstat 
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STAT_NAME VALUE COMMENTS 

NUM CPUS 8 Number of active CPUs 

IDLE_TIME 29648458 Time (centi-secs) that CPUS have been in the idle state 

BUSY_TIME 6348349 Time (centi-secs) that CPUs have been in the busy state 

USER_TIME 4942391 Time (centi-secs) spent in user code 

SYS_TIME 1336523 Time (centi-secs) spent in the kernel 

IOWAIT TIME 3806135 Time (centi-secs) spent waiting for IO 

NICE TIME 22373 Time (centi-secs) spend in low-priority user code 

RSRC MGR_ CPU WAIT TIME 14195 Time (centi-secs) processes spent in the runnable state 
waiting 

LOAD 1 Number of processes running or waiting on the run queue 

NUM_CPU_CORES 8 Number of CPU cores 

NUM_CPU_SOCKETS 2 Number of physical CPU sockets 


PHYSICAL MEMORY_ BYTES 12619522048 Physical memory size in bytes 


VM IN BYTES 0 Bytes paged in due to virtual memory swapping 
VM OUT_BYTES 0 Bytes paged out due to virtual memory swapping 
FREE MEMORY _ BYTES 1529409536 Physical free memory in bytes 

INACTIVE MEMORY_BYTES 2112192512 Physical inactive memory in bytes 
SWAP_FREE_BYTES 8603631616 Swap free in bytes 

TCP_SEND SIZE MIN 4096 TCP Send Buffer Min Size 

TCP_SEND SIZE DEFAULT 16384 TCP Send Buffer Default Size 

TCP_SEND SIZE MAX 4194304 TCP Send Buffer Max Size 

TCP_RECEIVE SIZE MIN 4096 TCP Receive Buffer Min Size 

TCP_RECEIVE SIZE DEFAULT 87380 TCP Receive Buffer Default Size 

TCP_RECEIVE SIZE MAX 6291456 TCP Receive Buffer Max Size 

GLOBAL SEND SIZE MAX 1048576 Global send size max (net.core.wmem max) 
GLOBAL RECEIVE SIZE MAX 4194304 Global receive size max (net.core.rmem max) 


这 些 信息 对 找 出 数据 库 服务 器 上 是 否 存 在 消耗 CPU 资 源 的 其 他 应 用 特别 有 帮助 。 为 达到 这 个 目 
的 , 你 需要 根据 时 间 模 块 统计 信息 中 的 BUSY_TIME 值 来 对 比 CPU 使 用 率 。 如 果 这 两 个 值 相近 ,你 就 可 以 
知道 你 连接 的 数据 库 实例 占用 了 大 多 数 CPU 资 源 。 


4.2.2 ”时 间 模 型 统计 信息 


通过 查看 时 间 模 型 统计 信息 ， 你 可 以 知道 数据 库 引擎 代表 应 用 进行 哪 种 类 型 的 处 理 。 时 间 模 型 统 
计 信 息 的 目的 是 展示 执行 关键 操作 所 花费 的 时 间 统 计 ， 比 如 打开 新 会 话 、 解 析 SQL 语 名 以 及 利用 数据 
库 引 擎 ( SQL、PL/SQL、JAVA 和 OLAP ) 处 理 调 用 。 另 外 也 会 提供 一 些 关于 后 台 处 理 的 图 表 。 

由 两 个 独立 的 树 形 结构 组 织 而 成 的 一 小 部 分 图 表 ， 构成 了 时 间 模 型 统计 信息 : 其 中 一 个 是 数据 库 
实例 自身 的 后 台 处 理 , 另外 一 个 是 前 台 处 理 ( 应 用 执行 的 处 理 )。 图 4-2 和 图 4-3 不 仅 显 示 了 后 人 台 处 理 与 
前 台 处 理 的 相关 统计 信息 , 也 展示 了 它们 之 间 的 关系 。 比 如 , 根据 图 4-3，parse time elapsed 是 DB time 
的 子 节点 ， 也 是 hard parse elapsed time 的 上 层 节点 。 每 项 统计 信息 基本 上 可 以 根据 名 字 知 道 其 意义 。 
具体 的 描述 请 参照 Oracle Database Reference 手 册 中 的 “VS$SESS_TIME MODLE” 部 分 。 

background elapsed time 


Lbackground cpu time 
LRMAN cpu time (backup/restore) 


图 4-2 ”后 台 处 理 时 间 模 型 统计 信息 的 树 形 结 构 
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DB time 
DB CPU 
connection management call elapsed time 
sql execute elapsed time 
parse time elapsed 
hard parse elapsed time 
Lhard parse (sharing criteria) elapsed time 
Lhard parse (bind mismatch) elapsed time 
failed parse elapsed time 
Lfailed parse (out of shared memory) elapsed time 
repeated bind elapsed time 
sequence load elapsed time 
PL/SQL execution elapsed time 
inbound PL/SQL rpc elapsed time 
PL/SQL compilation elapsed time 
Java execution elapsed time 
OLAP engine elapsed time 
LOLAP engine CPU time 


图 4-3 ”前 人 台 处 理 时 间 模 型 统计 信息 的 树 形 结构 


由 于 时 间 模 型 统计 信息 被 分 成 了 两 个 树 形 结构 ， 所 以 可 以 对 DB time 和 background elapsed time 
进行 求 和 来 统计 处 理 的 合计 时 间 。 注 意 ， 这 两 个 统计 信息 都 包含 CPU 使 用 和 除了 空闲 等 待 级 别 等 待 事 
件 之 外 的 其 他 所 有 等 待 事件 的 总 和 (下 一 节 会 介绍 关于 等 待 级 别 的 详细 信息 )。 

树 形 结构 中 子 节点 记录 的 时 间 会 包含 在 父 节 点 中 。 但 这 并 不 代表 父 节 点 会 记录 所 有 子 节点 记录 的 
时 间 。 实 际 上 ， 有 些 操作 不 会 只 与 单独 的 一 个 子 节点 相关 联 ， 甚 至 有 些 操作 都 不 会 归于 任何 子 节点 。 

时 间 模 型 统计 信息 分 别 由 v$sys_time mode1l 和 v$sess time model 视 图 来 提供 系统 级 别 和 所 有 连接 
会 话 的 信息 。 此 外 , 在 12.1 多 租户 环境 下 ，v$con_sys time model 视 图 会 显示 容器 级 别 的 统计 信息 。 在 
这 些 动态 性 能 视图 中 ， 有 下 面 两 个 关键 列 。 

口 stat_name 标 识 统计 信息 。 

口 value 提 供 对 应 组 件 ( 数据库 实例 、 进 程 或 容器 ) 从 初始 化 开始 累积 的 总 时 间 (单位: 微 秒 )。 

对 于 会 话 级 别 的 统计 信息 (v$sess_time model ), 也 有 一 列 ( sid ) 用 来 标识 相关 会 话 。 并 且 在 12.1 
多 租户 环境 下 ， 也 同样 存在 一 列 ( con_id ) 用 来 标识 容器 。 

以 下 查询 基于 v$sess_time_model 视 图 ， 显 示 某 进程 从 启动 开始 花费 的 处 理 时 间 ( 97.3% 的 时 间 用 
来 执行 SQL 语句 ): 

SQL> WITH 

2 db time AS (SELECT sid, value 

3 FROM v$sess time model 

4 WHERE sid = 42 

5 AND stat name = "DB time') 

6 SELECT ses.stat name AS statistic, 

7 round(ses.value / 1E6, 3) AS seconds, 

8 round(ses.value / nullif(tot.value, 0) * 1E2, 1) AS "%" 
9 FROM v$sess time model ses, db time tot 

10 WHERE ses.sid = tot.sid 

11 AND ses.stat name <> "DB time' 


12 AND ses.value > 0 
13 ORDER BY ses.value DESC; 
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STATISTIC SECONDS % 
sql execute elapsed time 99.437 97.3 
DB CPU 4.46 4.4 
parse time elapsed 0.308 0.3 
connection management call elapsed time 0.004 .0 
PL/SQL execution elapsed time 0.000 0.0 
repeated bind elapsed time 0.000 0.0 


请 注意 , 在 本 例 中 ,百分比 是 根据 DB time 的 值 计算 的 ， 这 个 值 是 数据 库 引 擎 处 理 用 户 调 用 花费 的 
所 有 时 间 。 由 于 DB time 只 计算 数据 库 处 理 时 间 ， 数 据 库 引 警 等 待 用 户 调 用 的 时 间 花 费 并 不 包括 在 内 
因此 ， 仅 根据 时 间 模 型 统计 信息 提供 的 信息 并 不 能 确定 问题 是 在 数据 库 里 还 是 数据 库 之 外 。 此 外 ， 仅 
根据 时 间 模 型 统计 信息 也 无 法 解释 已 用 时 间 和 CPU 时 间 的 区 别 (比如 ， 上 例 中 只 有 4.4% 的 时 间 用 在 
CPU 上 )。 要 想 确 切 知道 到 底 发 生 了 什么 ， 就 需要 等 待 级 别 和 等 待 事件 ( 见 下 一 节 ) 的 信息 


平均 活动 会 话 数 


平均 活动 会 话 数 ( Average Number of Active Session，AAS ) 是 系统 级 别 DB time 的 增长 率 。 比 
如 ， 如 果 数 据 库 实例 的 BDtime 在 60 秒 内 增长 了 1860 秒 ， 那 么 平均 活动 会 话 数 为 31 ( 1860/60 )。 这 表 
示 在 60 秒 内 ， 大 约 有 31 个 进程 在 处 理 用 户 调用 


系统 级 别 的 平均 活动 会 话 数 是 一 个 重要 指标 ， 因 为 它 能 告诉 你 系统 的 负载 情况 。 一 般 来 说 ， 当 
系统 几乎 空闲 时 ， 这 个 值 要 比 CPU 核 数 低 得 多 。 相 反 ， 若 该 值 比 CPU 核 数 高 许多 ， 则 表示 系统 非常 


繁忙 。 不 得 不 说 由 于 这 是 个 平均 值 ， 会 有 很 多 信息 看 不 到 。 因 此 当 只 根据 该 信息 来 诊断 时 请 格外 注 
意 ， 尤 其 当 持 续 时 间 不 止 几 分 钟 时 

DB time 的 增长 率 也 可 以 用 来 计算 单独 的 会 话 。 那 样 的 话 ， 它 只 能 是 介 于 0 和 1 之 间 的 某 个 值 ， 
用 来 表示 会 话 活动 的 程度 。 如 果 值 是 0， 代 表 进 程 彻底 空闲 。 换 和 句 话说， 数据 库 引 擎 没有 做 处 理 
如 果 值 为 1， 代 表 进 程 正 忙于 处 理 用 户 调用 。 


4.2.3 等待 级 别 和 等 待 事件 


基于 时 间 模 型 统计 信息 ， 不 仅 可 以 确定 数据 库 实例 (会话 或 容器 ) 花费 了 多 少时 间 处 理 ， 也 能 知 
道 这 个 处 理 使 用 了 多 少 CPU。 当 这 两 个 值 相等 时 ,代表 数据 库 实例 并 没有 经 历 类 似 磁盘 IO 操作 、 网 络 
回路 或 者 锁 的 等 待 。 然 而 ， 当 这 两 个 值 不 同时 ， 为 了 分 析 性 能 问题 ， 你 需要 知道 服务 器 进程 正在 等 待 
哪些 资源 。 而 这 个 信息 就 来 自 等 待 事件 。 

由 于 等 待 事件 非常 多 ( 在 12.1 版 本 中 有 超过 1500 个 ), 为 了 简化 分 析 产 品 的 资源 使 用 , 等 待 事件 被 
分 成 13 个 等 待 级 别 ( 注意 ，10.2 版 本 中 是 12 个 )。 通过 查询 v$event_name 视 图 可 以 得 知 当 前 版 本 有 哪些 
等 待 事件 及 其 等 待 级 别 。 例 如 , 以 下 查询 显示 了 在 12.1.0.1 版 本 中 存在 的 等 待 级 别 , 每 个 级 别 包含 的 等 
待 事件 数 以 及 一 些 等 待 事件 ( Commit ) 所 属 的 等 级 级 别 : 

SQL> SELECT wait class, count(*) 

2 FROM v$event name 


3 GROUP BY rollup(wait class) 
4 ORDER BY wait class; 
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WAIT CLASS COUNT(*) 


Administrative 57 
Application 到 
Cluster 57 
Commit 4 
Concurrency 34 
Configuration 26 
Idle 119 
Network 28 
Other 1123 
Queueing 9 
Scheduler 10 
System I/0 34 
User I/0 51 

1569 


SQL> SELECT name 
2 FROM v$event -name 
3 WHERE wait class = “Commit ; 


remote log force - commit 

log file sync 

nologging standby txn commit 

enq: BB - 2PC across RAC instances 


v$system wait class 和 v$session wait_class 视 图 分 别 记录 了 系统 级 别 与 所 有 连接 会 话 的 等 待 事 
件 级 别 。 此 外 ， 在 12.1 多 租户 环境 下 ，v$con_system wait class 显 示 容器 级 别 的 统计 信息 。 这 些 动态 
性 能 视图 有 下 面 三 个 关键 列 。 
口 wait_class 标 识 等 待 级 别 。 
口 toal_waits 提 供 对 应 组 件 〈 数据 库 实例 、 会 话 或 容器 ) 从 初始 化 开始 累积 的 等 待 事 件数 。 
口 time_waited 提 供 对 应 组 件 ( 数据库 实 例 、 会 话 或 容器 ) 从 初始 化 开始 累积 的 总 等 待 时 间 ( 单 
位 : 百 分 之 一 秒 》 
当然 ， 对 于 会 话 级 别 的 统计 信息 ( v$session wait_class )， 同 样 存 在 列 ( sid ) 用 来 标识 对 应 的 
会 话 ， 并 且 在 12.1 多 租户 环境 下 ， 存 在 列 ( con id ) 用 来 标识 容器 。 接 下 来 的 例子 使 用 与 之 前 例子 一 
样 的 会 话 ( 在 CPU 上 花费 4.4% 的 DB time )。 用 这 个 例子 说 明 ， 如 何 对 会 话 执行 处 理 以 生成 一 个 简要 的 
资源 使 用 分 析 。 可 以 在 系统 级 别 和 容器 级 别 使 用 类 似 的 查询 。 只 需要 将 查询 涉及 的 动态 性 能 视图 更 改 
为 对 应 的 级 别 即 可 。 
SOL> SELECT wait class, 
2 round(time waited, 3) AS time waited, 
3 round(1E2 * ratio to report(time waited) OVER (), 1) AS "%" 
4 FROM ( 
5 SELECT sid, wait class, time waited / 1E2 AS time waited 
6 FROM v$session wait class 
7 
8 


WHERE total waits > 0 
UNION ALL 
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9 SELECT sid, 'CPU', value / 1E6 
10 FROM v$sess time model 

14 WHERE stat name = “DB CPU 

私 ) 

13 WHERE sid = 42 

14 ORDER BY 2 DESC; 


WAIT _ CLASS TIME WAITED % 


Idle 154.77 60.2 
User I/0 96.99 37.7 
CPU 4.46, ‘Ls 
Commit 0.85 .3 
Network 0.04 0.0 
Configuration 0.03 0.0 
Concurrency 0.02 0.0 
Application 0.01 0.0 


即便 已 经 开始 基于 等 级 级 别 的 资源 使 用 分 析 ， 大 多 数 时 候 你 仍然 需要 准确 的 信息 。 你 需要 等 待 事 
件 。 为 此 ， 数 据 库 引擎 分 别 通 过 v$system event 和 v$session event 视 图 来 提供 系统 级 别 和 所 有 连接 会 
话 的 等 待 事件 信息 。 此 外 ， 在 12.1 多 租户 环境 下 ，v$con_system event 视 图 提供 容器 级 别 信息 。 以 下 查 
询 用 来 说 明 如 何 对 会 话 执行 处 理 以 生成 详细 的 资源 使 用 分 析 ( 可 以 在 系统 级 别 和 容器 级 别 使 用 类 似 的 
查询 。 只 需要 将 查询 涉及 的 动态 性 能 视图 更 改 为 对 应 的 级 别 )， 使 用 的 是 与 前 面 例子 相同 的 会 话 。 


SQL> SELECT event, 


2 round(time waited, 3) AS time waited, 
3 round(1E2 * ratio to report(time waited) OVER (), 1) AS "%" 
4 FROM (人 


5 SELECT sid, event, time waited micro / 1E6 AS time waited 
6 FROM v$session event 

7 WHERE total waits > 0 

8 UNION ALL 

9 SELECT sid, 'CPU'’, value / 1E6 

0 FROM v$sess time model 

11 WHERE stat name = "DB CPU’ 

| 

13 WHERE sid = 42 

14 ORDER BY 2 DESC; 


EVENT TIME_WAITED % 
SQL*#Net message from client 154.790 6 

db file sequential read 96.125 37. 
CPU 4.461 


log file sync 

read by other session 

db file parallel read 

SQL*Net message to client 
cursor: pin 9 

enq: TX - row lock contention 
Disk file operations I/0 
latch: In memory undo latch 


>» 
Wy 
wn 
OOOOOoOoOoOoorPNO 
OOOoOoOoOoPWWwWJNPN 


SODO DSO SO 
© 
jh 
hi 
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在 上 面 的 输出 中 , 你 可 以 注意 到 DB time 只 占用 了 总 执行 时 间 的 39.8% ( 100-60.2 )。 实 际 上 , 剩 下 
的 60.2% 被 空闲 等 待 事件 占用 ( SQL*Net message from client )。 这 表示 在 60.2% 的 时 间 里 ， 数 据 库 引 
擎 在 等 待 应 用 提交 作业 。 这 个 资源 使 用 分 析 提 供 的 另 一 个 重要 的 信息 是 ， 当 数据 库 引擎 处 理 用 户 调 用 
时 ， 它 总 是 单 块 读 来 执行 磁盘 IO 操作 ( db file sequential read )。 所 有 其 他 的 等 竺 事件 和 CPU 使 用 
率 都 可 忽略 不 计 。 

对 于 一 些 等 待 事件 ， 比 如 与 磁盘 IO 操作 有 关 的 ， 你 或 许 想 要 知道 平均 延迟 的 信息 。 实 际 上 ， 如 果 
你 有 这 些 信息 , 就 可 以 对 比 当 前 性 能 与 预期 性 能 ( 你 应 该 知道 用 来 存储 数据 库 的 磁盘 IO 子 系统 的 预期 
性 能 )。 比 如 ， 可 以 基于 视图 ( 比如 v$system_event ) 执行 查询 来 计算 某 一 等 待 事件 的 平均 延迟 。 

SQL> SELECT time waited micro/total waits/1E3 AS avg wait ms 


2 FROM v$system event 
3 WHERE event = 'db file sequential read'; 


AVG WAIT_MS 


9.52927176 


上 面 这 个 查询 计算 出 来 的 平均 值 隐 藏 了 很 多 信息 ，Oracle 数 据 库 提供 了 一 个 视图 ， 该 视图 可 以 在 
系统 级 别 为 每 个 等 待 事件 提供 直方 图 。 et _histogram。 它 有 下 面 三 个 关键 列 。 

口 event 是 等 待 事件 的 名 称 。 

口 wait time ni 代表 每 个 直方 图 李 的 上 限 值 (不 包含 在 内 )。 

口 wait_count 是 与 等 待 事件 关联 的 直方 图 桶 数 。 

比如 , 接 下 来 的 查询 显示 多 数 ( 45.7% ) 等 待 事件 在 4 毫秒 和 8 毫秒 的 桶 内 , 约 24%( 3.27+2.75+18.37 ) 
在 小 于 4 毫秒 的 桶 内 ， 约 10% ( 5.96+2.66+1.34+0.17+0.01 ) 在 16 毫 秒 以 及 更 大 的 桶 内 。 


SQL> SELECT wait time milli, wait count, 100*ratio to report(wait count) OVER () AS "%" 
2 FROM v$event histogram 
3 WHERE event = "db file sequential read'; 


WAIT_TIME MILLI WAIT_ COUNT % 
J 348528 3.27 
2 293508 2.75 
4 1958584 18.37 
8 4871214 45.70 
16 2106649 19.76 
32 635484 5.96 
64 284040 2.66 
128 143030 1.34 


256 18041 0.17 
512 588 0.01 
1024 105 0.00 
2048 1 0.00 


上 面 的 信息 主要 显示 最 大 值 是 多 少 。 在 本 例 中 , 一 些 磁盘 IO 操作 远 远 超 出 预期 ( 在 64 毫 秒 的 桶 与 
2 秒 的 桶 之 间 )。 尽 管 这样 的 操作 不 多 , 却 能 表明 要 么 磁盘 IO 系统 (或 其 中 一 个 组 件 ) 太 小 , 要 么 配置 
或 硬件 有 问题 。 
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4.2.4 系统 和 会 话 统计 信息 


除了 时 间 模 块 统计 信息 和 等 竺 事件， 数据 库 引 擎 同样 会 记录 数 百 个 〈 在 12.1 版 本 中 有 超过 850 个 ) 
附加 统计 信息 , 比如 某 一 操作 执行 的 次 数 或 某 一 函数 处 理 的 数据 量 。 可 以 分 别 在 v$sysstat 和 v$sesstat 
视图 中 查 到 系统 级 别 和 所 有 连接 会 话 的 相关 信息 ,此 外 , 在 12.1 多 租户 环境 中 ,也 可 以 在 v$con_sysstat 
视图 中 找到 容器 级 别 的 信息 。 

在 v$sysstat 视 图 中 有 下 面 两 个 关键 列 。 

口 name 标 识 统计 信息 ( 大 部 分 的 简要 描述 请 参考 Oracle Database Reference 手 册 )。 

口 value 提 供与 统计 信息 相关 的 指标 。 在 大 多 数 情况 下 ,value 显 示 的 是 从 数据 库 实例 启动 开始 的 

累计 值 ， 但 并 不 是 所 有 的 统计 信息 都 是 这 样 。 

让 我 们 来 看 两 个 查询 ,这 两 个 例子 会 显示 动态 性 能 视图 ， 比 如 v$sysstat 提 供 的 信息 。 第 一 个 查询 
基于 持续 增加 的 计数 器 返回 统计 信息 。 在 这 里 , 这 些 计 数 器 代表 logon 数 、commit 数 和 数据 库 实例 启 动 
后 在 内 存 中 的 排序 数 。 


SQL> SELECT name, value 
2 FROM v$sysstat 
3 WHERE name IN ('logons cumulative', 'user commits', 'sorts (memory)'); 


NAME VALUE 
logons cumulative 1422 
user commits 1298103 
sorts (memory) 770169 


第 二 个 查询 返回 的 统计 信息 显示 磁盘 1/O 操 作 处 理 的 总 数据 量 。 


SQL> SELECT name, value 
2 FROM v$sysstat 
3 WHERE name LIKE “physical % total bytes’'; 


physical read total bytes 9.1924E+10 
physical write total bytes 4.2358E+10 


v$con_sysstat 视 图 与 v$sysstat 视 图 的 结构 一 样 ,然而 , v$sesstat 视 图 有 很 大 不 同 。 尽 管 有 列 ( sid ) 
用 来 标识 统计 信息 所 属 的 会 话 ， 但 没有 提供 name 列 。 为 了 获得 统计 信息 的 名 称 ， 就 必须 使 用 另 一 个 包 
含 所 有 统计 信息 列表 的 视图 v$statname 与 v$sesstat 进 行 联合 查询 。 以 下 查询 展示 了 如 何 利 用 这 两 个 视 
图 来 获取 当前 会 话 的 PGA 内 存 使 用 率 信息 (会 返回 两 个 值 ， 当前 内 存 使 用 的 总 数 和 会 话 初始 化 后 分 配 
的 最 大 内 存 数 ): 


SQL> SELECT sn.name, ss.value 
2 FROM v$statname sn, v$sesstat ss 
3 WHERE sn.statistic# = ss.statistic# 
4 AND sn.name LIKE 'session pga memory%” 


5 AND ss.sid = sys context('userenv','sid'); 
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session pga memory 1723880 
session pga memory max 2313704 


为 了 避免 基于 sid 列 的 限制 ,以 上 查询 可 以 使 用 vsmystat 视 图 。 实际 上 ,针对 会 话 查 询 ， 还 可 以 使 
用 提供 相同 信息 的 v$sesstat。 唯 一 不 同 的 是 这 个 视图 只 显示 当前 会 话 的 统计 信息 。 


提示 大 多 数 情 况 下 , 要 开始 分 析 ， 首先 需要 把 响应 时 间 分 解 成 CPU 消 耗 与 等 待 事件 。 如果 一 个 会 话 
总 是 占用 CPU， 没 有 任何 等 待 事件 ,会话 统计 信息 会 有 助 于 了 解 当前 会 话 到 底 在 做 什么 。 


4.2.5 度量 值 


前 几 节 介绍 的 动态 性 能 视图 里 提供 的 多 数 统计 信息 值 都 是 累积 的 。 以 此 为 基础 ， 数 据 库 引 擎 计算 
出 一 个 度量 值 ( 根据 版 本 的 不 同 , 在 200~300 之 间 ), 而 这 个 值 对 监控 特别 有 用 。 这 些 值 在 v$metricname 
视图 中 列 出 。 比 如 ， 从 11.2 版 本 之 后 ， 会 有 一 个 值 用 来 显示 数据 库 服务 器 每 秒 的 CPU 使 用 ( 基于 OS 统 
计 信 息 )。 以 下 查询 展示 了 这 个 值 在 vimetricname 视 图 中 的 内 容 : 

SQL> SELECT metric id, metric unit, group_id, group name 


2 FROM v$metricname >; 
3 WHERE metric name = 'Host CPU Usage Per Sec'; 


METRIC ID METRIC UNIT GROUP_ID GROUP_NAME 
2155 CentiSeconds Per Second 2 System Metrics Long Duration 
2155 CentiSeconds Per Second 3 System Metrics Short Duration 


正如 你 在 上 面 这 个 查询 输出 中 所 看 到 的 , 一 个 度量 值 有 一 个 ID、 一 个 衡量 单位 和 它 所 在 组 的 ID 和 
名 称 ( 本 例 它 属于 两 个 组 )。 

请 注意 度量 值 是 基于 若干 衡量 单位 计算 出 来 的 。 其 中 一 些 ， 像 上 面 例子 中 的 ， 代 表 使 用 率 或 每 秒 
的 事件 数 。 其 他 的 则 是 根据 每 个 事务 、 请 求 、 调 用 或 绝对 值 的 平均 值 计算 出 来 的 。 

度量 值 关联 的 组 定义 了 计算 间隔 和 信息 提供 的 时 长 。 如 果 一 个 度量 值 关 联 两 个 组 ， 正 如 上 面 的 例 
子 那样 ， 这 表示 数据 库 引 擎 分 别 计算 两 个 度量 值 , 并 且 它 们 都 有 各 自 的 间隔 和 保存 期 。v$metricgroup 
视图 提供 了 关于 组 的 信息 。 下 面 这 些 组 存在 于 12.1 版 本 中 ( 其 他 版 本 中 组 的 数量 可 能 不 同 ): 


SQL> SELECT * 
2 FROM v$metricgroup 
3 ORDER BY group id; 


GROUP_ID NAME INTERVAL SIZE MAX INTERVAL 
0 Event Metrics 6000 
1 Event Class Metrics 6000 60 
2 System Metrics Long Duration 6000 60 
3 System Metrics Short Duration 1500 12 
4 Session Metrics Long Duration 6000 60 
5 Session Metrics Short Duration 1500 1 
6 Service Metrics 6000 60 


7 File Metrics Long Duration 60000 6 
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9 Tablespace Metrics Long Duration 6000 0 
10 Service Metrics (Short) 500 24 
11 I/0 Stats by Function Metrics 6000 60 
12 Resource Manager Stats 6000 60 
13 WCR metrics 6000 60 
14 WIM PC Metrics 500 24 


interval_size 列 显示 度量 值 所 关联 的 组 的 计算 间隔 ,以 百 分 之 一 秒 为 单位 。 例如 ,System Metrics 
Long Duration 组 的 度量 值 每 60 秒 计算 一 次 。 max_interval 列 显示 该 组 间隔 保留 的 最 大 值 。 例 如 ， System 
Metrics Long Duration 组 的 最 大 值 为 60。 因 此 对 于 这 个 组 ， 前 一 个 小 时 的 信息 都 是 可 用 的 。 

度量 值 自身 的 值 来 自若 干 视图 。 实 际 上 ， 有 些 视图 是 特别 针对 一 些 度量 值 组 的 。 例 如 ， 对 于 组 2 
和 组 3，v$sysmetric 和 v$sysmetric_history 视 图 分 别 显示 了 当前 值 和 历史 值 。 简 单 来 说 ， 对 于 大 多 数 
度量 值 , 都 可 以 使 用 vimetric 和 v$metric_history 视 图 。 举 例 说 明 ， 下 面 的 查询 显示 Host CPU Usage Per 
Sec 的 当前 度量 值 ( 注意， 第 一 个 度量 值 计算 花费 了 60 秒 ， 第 二 度量 值 只 花费 了 15 秒 ): 


SQL> SELECT begin time, end time, value, metric unit 
2 FROM v$metric 
3 WHERE metric name = 'Host CPU Usage Per Sec'; 


BEGIN TIME END_TIME VALUE METRIC_UNIT 


2014-04-28 01:56:00 2014-04-28 01:57:00 168.137173 CentiSeconds Per Second 
2014-04-28 01:56:45 2014-04-28 01:57:00 159.786951 CentiSeconds Per Second 


4.2.6 ”当前 会 话 状态 


通过 v$session 视 图 , 不 仅 可 以 知道 有 哪些 会 话 存 在 , 还 可 以 知道 它们 现在 都 在 做 什么 。 由 于 这 个 
动态 性 能 视图 包含 了 太 多 列 ( 例如 ，10.2.0.5 版 本 中 为 82 列 ，12.1.0.1 版 本 中 为 101 列 )， 这 里 不 会 一 一 
介绍 (更 多 信息 请 参考 Oracle Database Reference 手 册 )。 下 面 列 出 可 以 从 v$session 视 图 中 获取 的 最 重 
要 的 信息 以 及 这 些 信息 所 在 的 列 。 
口 会 话 的 标识 ( sid、serial#、saddr 和 audsid ), 会 话 是 属于 BACKGROUND 会 话 还 是 USER 会 话 ( type )， 
以 及 会 话 进行 初始 化 的 时 间 ( logon_time )。 

口 打开 会 话 的 用 户 的 标识 ( username 和 user# )、 当 前 模式 ( schemame ) 和 用 于 连接 到 数据 库 引 擎 
的 服务 的 名 称 ( service_name )。 

口 使 用 会 话 的 应 用 ( program )、 启 动 会 话 所 在 的 机 器 ( machine )、 会 话 的 进程 ID ( process ) 以 
及 启动 会 话 的 操作 系统 用 户 的 名 称 (osuser )。 

口 服务 器 端 进程 的 类 型 ( server ) ( 可 以 是 DEDICATED 、SHARED 、PSEUDO 、POOLED 或 NONE ) 以 及 服 
务 器 端 进程 的 地 址 ( paddr )。 

口 当前 活动 事务 的 地 址 (taddr )。 

口 会 话 状 态 ( status ) ( 可 以 是 ACTIVE 、INACTIVE 、KILLED 、SNIPED 或 CACHED ) 以 及 这 个 状态 持续 
了 多 少 秒 (last_call_et )。 处 理性 能 问题 时 ， 通 常 只 关注 ACTIVE 的 会 话 。 

口 正在 执行 的 SQL 语句 的 类 型 ( command )、 与 SQL 语句 相关 的 游标 的 标识 ( sql_address 、 

sql_hash_ value、sql_ id 和 sql_child number )、 执 行 的 开始 时 间 ( sql exec_start ) 以 及 SQL 
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语句 的 执行 ID ( sql_exec_id )。 执 行人 DD 是 一 个 整数 值 ， 与 sq]_exec_start 一 起 标识 出 某 个 特定 
执行 。 由 于 同样 的 游标 每 秒 会 被 执行 多 次 ， 这 会 变 得 很 重要 ( 注意 sql_exec_start 列 的 数据 类 
型 是 DATE )。 

口 执行 过 的 前 一 个 游标 的 标识 (prev_sql address、 prev_hash_value、 prev_sql_ id 和 prev_child 
number )、 前 一 个 执行 的 开始 时 间 ( prev_exc_start ) 以 及 前 一 个 游标 的 执行 ID( prev_exec id )。 

口 如 果 执 行 的 是 PL/SQL 调 用 ,那么 该 信息 包括 ， 被 调用 的 顶层 程序 与 子 程序 的 标识 
(plsql entry object id 和 plsql entry_subprogram id ), 以 及 当前 正在 执行 的 顶层 程序 和 子 程 
序 (plsq_object_id 和 plsql_subprogram_id )。 注 意 ， 如 果 会 话 正在 执行 某 个 SQL 语句 ， 则 会 
将 plsql object id 和 plsql subprogram id 设置 为 NULL。 

口 会 话 属性 ( client identifier、module、action 和 client_info ) (如果 使 用 会 话 的 应 用 设置 这 
些 属性 )。 

口 如 果 会 话 当前 正在 等 待 ( 这 种 情况 下 会 将 state 列 设置 为 WAITING )， 那 么 该 信息 包括 ， 会 话 正 
在 等 待 的 等 待 事件 的 名 称 (event )、 其 等 待 级 别 ( wait_class 和 wait_class# )、 关 于 等 待 事件 
的 详细 信息 (pitext、p1、plraw、p2text 、p2、p2raw、p3text 、p3 和 p37raw )， 以 及 会 话 已 经 
等 待 该 等 待 事件 的 时 间 ( seconds_in_wait， 自 11.1 版 本 起 为 wait time micro )。 注意 如 果 state 
列 不 是 NAITING， 那 么 表示 会 话 在 使 用 CPU ( 如 果 status 列 等 于 ACTIVE )。 这 种 情况 下 ， 与 等 待 
事件 相关 的 列 会 包含 关于 上 一 次 等 待 的 信息 。 

口 会 话 是 否 被 男 一 个 会 话 所 阻止 ( 如 果 是 ， 则 会 将 blocking_session_status 设 置 为 VALID ); 如 果 
会 话 正 在 等 待 ， 那 么 是 哪个 会 话 正在 阻止 它 〈blocking_instance 和 blocking_session )。 

口 如 果 会 话 当 前 被 阻止 并 且 正 在 等 待 某 个 特定 行 ( 例如 ， 等 待 某 个 行 锁 )， 那 么 该 信息 是 会 话 当 
前 正在 等 待 的 行 的 标识 (row wait obj#、 row wait file#、 row wait block# 和 frow wait row# )。 
如 果 会 话 未 在 等 待 某 个 被 锁定 的 行 ， 那么 row_wait_obj# 列 等 于 值 -1。 

除了 v$session 视 图 之 外 ， 还 有 专门 提供 特定 信息 的 其 他 动态 性 能 视图 。 比 如 ，v$session_wait 视 

图 仅 提 供与 等 待 事件 相关 的 列 ， 而 v$session_blockers 视 图 仅 提 供与 被 阻止 会 话 相关 的 列 。 


4.2.7 ”活动 会 话 历 史 


上 一 节 介 绍 过 , 通过 v$session 视 图 可 以 知道 所 有 连接 会 话 的 当前 状态 。 即 使 这 样 的 信息 有 用 , 却 
也 并 不 足以 用 来 分 析 性 能 问题 。 实 际 上 , 想 要 分 析 成 功 , 就 必须 知道 一 个 会 话 在 一 段 时 间 内 做 了 什么 ， 
而 不 是 仅仅 在 某 一 时 刻 做 了 什么 。 这 就 是 活动 会 话 历史 (ASH ) 的 作用 ， 它 可 以 帮助 你 获取 会 话 状态 
的 历史 信息 。 


注意 ”Diagnostics Pack 选 件 必 须 有 许可 才能 使 用 ASH。 如 果 control_management_pack_access 默 认 设 
置 为 none，ASH 会 被 禁用 。 


与 SQL 跟踪 相 比 ，ASH 的 主要 优势 在 于 ASH 总 是 处 于 启用 状态 ， 因 此 可 以 在 需要 时 随时 查看 。 正 
是 由 于 这 个 原因 ， 它 对 于 不 能 重 现 的 性 能 问题 分 析 非 常 有 用 。 你 仅 需 要 等 到 系统 经 历 性 能 问题 后 去 分 
析 ASH 的 信息 即 可 。 
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为 了 生成 ASH 的 历史 信息 ， 后 台 进 程 (MMNL ) 会 在 每 秒 执行 以 下 三 个 操作 

口 对 所 有 会 话 状态 取样 ( 它 的 执行 内 容 类 似 查 询 v$session 视 图 ) 

口 忽略 等 待 空闲 等 待 级 别 事件 的 会 话 数据 。 

口 把 余下 的 数据 存 人 SGA 的 内 存 缓冲 区 中 

图 4-4 为 示例 图 解 。 你 可 以 注意 到 会 话 1 在 等 待 用 户 1/0 级 别 的 事件 ， 而 会 话 2 在 使 用 CPU, 会话 3 和 
会 话 4 处 于 空闲 状态 。 


Sampleld 19 20 21 22 23 24 25 26 27 28 29 30 31 
1 1 1 1 1 I 1 


pb 8” A” 必 $B 
a 


图 4-4 MMNL 进 程 取 样 ， 一 秒 内 所 有 会 话 的 状态 
如 图 4-4 所 示 , MMNL 取 样 的 进程 产生 的 数据 与 表 4-1 的 汇总 数据 类 似 。 这 里 需要 注意 两 点 。 首先 ， 
活动 会 话 历 史 里 总 是 会 记录 至 少 持续 一 秒 的 操作 。 其 次 ， 即 使 会 话 3 有 过 一 些 活动 ， 但 也 不 会 记录 在 
活动 会 话 历 史 中 。 
表 4-1 针对 图 4-4 示 例 的 负载 ， 由 MMNL 生 成 的 样 例 


样 例 ID 时 间 惟 会 话 SQL ID 活 动 
20 06:28:09 1 gd90ygn1j4026 CPU 
20 06:28:09 2 Sm6muSpd9w028 CPU 
21 06:28:10 1 gd90ygn1j4026 CPU 
21 06:28:10 3 Sm6muSpd9w028 CPU 
22 06:28:11 ] gd90ygn1j4026 User IO 
22 06:28:11 2 Sm6muSpd9w028 CPU 
23 06:28:12 1 gd90ygn1j4026 User IO 
23 06:28:12 2 Sm6mu5pd9w028 CPU 
24 06:28:13 1 7ztv2z24kw0s0 CPU 
24 06:28:13 区 Sm6muS$pd9w028 CPU 
25 06:28:14 2 Sm6muSpd9w028 CPU 
27 06:28:16 1 d9gdxSa4gcl3y CPU 
28 06:28:17 1 luaz41lwrxw03k User IO 
29 06:28:18 luaz41wWrxw03k CPU 
30 06:28:19 1 luaz41wWTrXw03k User IO 
31 06:28:20 1 1uaz41wrxw03k User IO 


基于 表 4-1 中 的 数据 ， 可 以 派生 出 以 下 信息 

口 会 话 1 活动 时 间 占 总 时 间 的 83% ( 12 秒 内 10 个 取样 ) 并 且 至 少 执行 了 4 个 不 同 的 SQL 语句 。CPU 
占用 了 一 半 的 处 理 时 间 ( 10 秒 内 5 个 取样 )， 另 一 半 时 间 用 来 执行 磁盘 IO 操作 。 

口 会 话 2 活动 时 间 占 总 时 间 的 50% ( 12 秒 内 6 个 取样 )。 这 期 间 CPU 一 直 在 执行 SQL ID 为 
5m6mu5pd9w028 的 SQL 

口 会 话 3 和 会 话 4 处 于 100% 空 闲 状态 ( 12 秒 内 0 个 取样 ) 


活动 会 话 历 史 缓 冲 区 
当 数 据 库 实例 启动 时 ， 会 在 $SGA 中 生成 一 个 缓冲 区 用 来 存放 活动 会 话 历 史 。Oracle 的 设计 目的 
是 在 内 存 中 保存 一 个 小 时 的 活动 。 可 以 执行 以 下 查询 来 获取 缓冲 区 大 小 以 及 存放 了 多 久 的 信息 : 


SQL> SELECT pool, bytes 
2 FROM v$sgastat 
3 WHERE name = 'ASH buffers'; 


shared pool 14680064 


J 


SQL> SELECT max(sample time) - min(sample time) AS interval 
2 FROM v$active session history; 


INTERVAL 


+000000000 02:25:30.293 
ee < 
可 以 通过 v$active_session_history 视 图 来 查询 存储 在 活动 会 话 历 史 中 的 数据 ,视图 中 的 许多 列 与 
v$session 视 图 的 意义 相同 ( 详细 信息 请 参考 4.2.6 节 ), 就 像 v$session 视 图 一 样 , v$active_session history 
视图 的 列 与 使 用 版 本 有 很 大 关系 ( 比如 ，10.2.0.5 版 本 有 50 列 ，12.1.0.1 版 本 有 101 列 )。 与 v$session 视 
图 相 比 ，v$active_session_history 视 图 少 了 一 些 列 ， 其 中 一 些 列 的 内 容 也 有 所 不 同 ， 还 有 一 些 列 仅 
存在 于 v$active_session_history 视 图 中 。 下 面 列 出 了 仪 存 在 于 v$active_session_history 视 图 中 的 重 
要 列 或 内 容 不 同 的 列 ( 更 多 信息 请 参考 Oracle Database Reference 手 册 ) 
口 sample_id 是 MMNL 取 样 时 的 标识 符 。 注 意 ， 在 活动 会 话 历史 中 ， 它 并 不 用 来 标识 一 列 
口 sample_ time 是 MMNL 取 样 时 的 时 间 戳 。 因 此 ， 可 以 基于 此 列 重 现 每 个 会 话 的 活动 。 
口 session_state 是 会 话 的 状态 。 该 列 值 是 WAITING 或 ON CPU 
口 如 果 会 话 在 等 待 ， 那 么 time_waited 列 就 是 会 话 等 待 时 间 的 总 微 秒 数 。 为 了 防止 一 个 等 待 事件 
会 跨越 两 个 或 者 更 多 的 取样 ， 实 际 等 待 时 间 会 取 自 最 后 一 个 取样 ， 对 于 其 他 的 取样 ， 
time_waited 列 将 为 0。 以 下 例子 显示 会 话 等 待 锁 7.4 秒 : 
SQOL> SELECT sample time, event, time waited 
2 FROM v$active session history 


3 WHERE session id = 137 
4 ORDER BY sample time; 


106 第 4 章 实时 分 析 不 可 重 现 的 问题 


SAMPLE_TIME EVENT TIME_WAITED 


27-APR-14 03.10.50.245 PM enq: TM - contention 


0 
27-APR-14 03.10.51.245 PM enq: TIM - contention 0 
27-APR-14 03.10.52.245 PM enq: TM -= contention 0 
27-APR-14 03.10.53.245 PM enq: TIM - contention 0 
27-APR-14 03.10.54.245 PM enq: TIM - contention 0 
27-APR-14 03.10.55.245 PM enq: TIM - contention 0 
27-APR-14 03.10.56.245 PM enq: TM - contention 0 
27-APR-14 03.10.57.245 PM enq: TM - contention 7390676 


口 对 于 执行 的 SQL 语 句 , 若干 列 提供 执行 计划 信息 。 特别 是 它 的 值 ( sql_plan_hash_value ) 和 活 
动 操作 (sql plan line id、sql plan operation 和 sql_plan _options )。 

口 从 11.1 版 本 之 后 , 根据 时 间 模 型 分 析 定 义 的 分 类 , 若干 标记 用 来 指出 执行 的 操作 ( in_connection_ 
mgmt inparse ,in hard parse\in sql execution\in plsql execution in_plsql rpc in plsql_ 
comilation、in _ java_execution in_bind ,in_cursor_ close 和 11.2 版 本 之 后 的 in_sequence lo0ad )。 

口 对 于 并 行 执行 的 SQL 语句 ， 也 有 对 应 并 行 查 询 的 信息 ( qc_instance id、qc_session id 和 11.1 
版 本 之 后 的 qc_session serial# )。 

有 了 v$active_session_history 视 图 中 的 信息 ， 就 可 以 分 析 数 据 库 引 擎 在 处 理 期 间 花 费 的 时 间 。 
强调 一 下 ,之 所 以 是 统计 分 析 是 因为 数据 是 基于 取样 的 。 因 此 ， 更 多 的 取样 才 会 产生 更 准确 的 结果 。 
总 之 ， 由 于 每 秒 只 会 取样 一 次 并 且 只 保存 一 个 活动 会 话 ， 因 此 准确 性 比 不 上 不 基于 取样 的 方法 ( 比如 
SQL 跟踪 )。 然 而 在 很 多 时 候 ， 分 析 能 提供 足够 的 信息 来 指出 性 能 问题 的 成 因 。 

针对 v$active_session_history 视 图 的 典型 查询 包含 以 下 部 分 。 

口 对 sample_time 进 行 限制 来 关注 某 个 特定 时 间 段 。 

口 根据 一 列 或 多 列 的 聚合 查询 来 获取 处 理 的 相关 信息 , 如 会 话 ID ( session_id ), 执行 游标 的 SQL 
语句 ( sql_id )， 或 者 执行 处 理 的 应 用 (program )。 

口 取样 的 计数 。 由 于 每 个 取样 都 是 一 秒 ， 取 样 的 数量 会 接近 DB time。 


敬告 要 对 DB time 、CPU 时 间或 等 待 事 件 的 总 时 间 估 值 ， 需 对 取样 计数 。 但 请 注意 ， 使 用 
sum(time waited) 这 样 的 简单 表达 式 聚 合 数 是 错 的 。 因 为 事件 被 取样 的 可 能 性 与 事件 长 度 有 关 。 


例如 ,以 下 查询 返回 的 是 五 分 钟 内 根据 它们 的 DB time 排 序 的 排名 前 十 的 SQL 语句 (注意 ,比如 排 
名 第 一 的 SQL 语句 执行 了 1008 秒 ， 占 用 了 29.9% 的 DB time )。 
SQL> SELECT activity pct， 


2 db time， 

3 sql id 

4 FROM ( 

5 SELECT round(100 * ratio to report(count(*)) OVER (), 1) AS activity pct, 

6 count(*) AS db time, 

7 sql id 

8 FROM v$active session history 

9 ”WHERE sample time BETWEEN to timestamp('2014-02-12 -22:12:30', 'YYYY-MM-DD HH24:MI:SS') 
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10 AND to timestamp('2014-02-12 22:17:30', 'YYYY-MM-DD HH24:MI:SS') 
11 AND sql id IS NOT NULL 

12 GROUP BY sql id 

13 ORDER BY count(*) DESC 


15 WHERE rownum <= 10; 


ACTIVITY_PCT DB_TIME SQL ID 


29.9 1008 c13Ssma6TkTr27< 
i.3 382 0yas01u2p9ch4 
了 ,之 376 Oy1iprvxqc2ra9 
9.5 321 7hk2m2702ua08g 
8.2 277 bymb3ujkr3ubk 
7.8 263 8dqovimjngj7t 
5.8 196 8z3542ffmp562 
4.2 142 Obzhqhhj9mpaa 
2.8 93 Smddt5kt45rg3 
103 44 Ow2qpuc6u2zsp 


如 果 你 使 用 Enterprise Manager 12c ( Cloud Control 或 Express )， 则 可 以 访问 ASH Analytics 获 取 活 动 
会 话 历史 的 信息 。 使 用 ASH Analytics 可 以 直接 访问 v$active_session_history 视 图 执行 分 析 而 不 用 写 
SQL 查询 。 可 以 简单 地 在 数据 库 实 例 经 历 的 时 间 线 和 负载 概况 的 图 表 上 选取 一 个 时 间 段 ( 如 图 4-5 所 
示 ), 选 出 想 要 聚合 的 一 块 或 多 块 数据 ( 下 拉 列 表 人 允许 包含 多 达 24 个 选择 ), 然后 选择 数据 显示 的 格式 。 


图 4-5 在 ASH Analytics 上 选择 分 析 的 时 间 段 


注意 尽管 ASH Analytics 是 Enterprise Manager 的 特性 ， 但 也 需要 在 数据 库 端 安装 一 些 对 象 。 这 些 对 象 
只 在 11.2.0.4 版 本 之 后 才 会 被 默认 安装 。 在 之 前 的 版 本 中 是 需要 手工 安装 的 。 若 未 安装 这 些 对 象 ， 
使 用 ASH Analytics 时 ，Enterprise Manager 会 建议 你 安装 。 注 意 ，10.2 版 本 不 支持 ASH Analytics。 


可 以 根据 以 下 三 种 主要 的 格式 来 排列 数据 。 
口 activity chart 显 示 所 选 时 间 段 中 平均 活动 会 话 数 的 变化 。 图 4-6 显 示 了 在 图 4-5 中 选择 的 5 分 钟 内 
排名 前 十 的 SQL 语 句 的 活动 会 话 数 。 


10:12:30 PM 10:13:05 PM 10:13:40PM 10:14:15PM 10:14:50PM 10:15:25 PM 10;16:00 PM 10;:16:35 PM 10:17:10 PM 


图 4-6 ”activity chart 显 示 图 4-5 选 择 的 时 间 段 中 排名 前 十 的 SQL 语 句 


口 top consumer table 显 示 选 择 的 时 间 段 中 消耗 最 大 的 平均 活动 会 话 数 。 注 意 在 这 


activity chart 不 同 的 区 域 。 例 如 ， 图 4-7 显 示 了 ， 在 图 4-5 选 择 的 时 间 有 段 里 ， 


文 里 可 以 选择 
哪些 SQL 语 Pte T 


最 多 的 DB time。 注意 , 将 鼠标 停 在 activity 的 条 上 时 , 也 可 以 看 到 SQL 语 句 执行 的 一 些 活动 信息 。 
例如 ， 在 图 4-7 中 ， 排 名 第 一 的 SQL 语 句 花费 了 29% 的 时 间 用 来 等 等 用 户 1/O 等 待 级 别 的 事件 


SQLID I By WaitCass | Tune SQL Se 区 io 和 J 
| saect [saLD Activity (Average Active Sessions) 

Dr i 7 

口 。 oyasoluzpgdh4 OE 

回 0ylprvxqcza9 ti 1 

[LL] zhk2m2702wa0g i 1 7 

回 bymb3ujkr 3ubk el 、 

口 8dqovimjngj7t a 

[LL 8z3542ffmp562 i .65 

LL dbzhqhhjompaa Us， 

口 smddt5kt45rg3 而 .31 

LD Oruh367af7gbw 故 .15 

Others (ime 


图 4-7 top consumer 表 显示 在 图 4- 


口 load map 显 示 的 信息 


5 选择 的 时 间 段 里 排名 前 十 的 SQL 语句 


与 top consumer 表 很 像 ， 不 同 的 是 用 了 treemap 而 非 表 。 例 如 ， 


图 4-8 显 示 J 


与 图 4-7 同 时 间 段 的 数据 。 同 样 ， 也 可 以 把 鼠标 悬 停 在 load map 的 一 个 矩形 上 获取 详细 信息 
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Mode | Advanced ‘vw | |SQLID ~ 


Dyasd lodh4 


£ Somatri 27c 
bs 


cli3smacrkr27c 

1012.00 Samples 

3.37 Average Active Sessions 

Distinct SQL IDs; 1.00 

Distinct Session IDs; 50.00 

Distinct Instance IDs; 1,00 a 
Distinct Transaction IDs: 0,00 2m2702a00 


图 4-8 ”load map 表 显示 在 图 4-5 选 择 的 时 间 段 里 排名 前 五 的 SQL 语 句 


& 管 activity chart 和 load map 可 用 来 显示 数据 ”= 但 在 ASH Analytics 里 它们 扮演 着 其 他 重要 的 角色 。 
实际 上 ， 可 以 通过 选择 一 个 或 者 多 个 top consumer 来 限制 分 析 的 数据 。 换 名 话说 ， 可 以 利用 它们 定义 
过 滤器 来 应 用 到 图 表 里 。 例 如 ， 可 以 执行 以 下 操作 : 

口 显示 top SQL 语句 并 选择 最 耗 时 的 部 分 ( cl3sma6rkr27c ); 

口 显示 top wait class 并 选择 最 耗 时 的 部 分 用户 LO ); 

口 显示 top wait event 并 选择 最 耗 时 的 部 分 ( db file sequential Tead ); 

口 显示 top module。 

图 4-9 显 示 了 这 些 操 作 的 结果 。 注意 ，load map 顶 端 定义 了 过 滤器 。 基 于 这 个 图 ， 可 以 推断 出 选择 
时 间 段 内 的 全 部 负载 是 由 单个 模块 产生 的 (New Order )。 


Flters SQL ID: cl3sma6rkr27c X Wait Class: User IJO X Wait Event: db file sequentiairead X 


Actvity | 国 LoadMap | 


[Mdule jy| Show | | Total Activity | | CPU Cores 


7 


强 New Order 


0 
10:12:35 PM 10:13:10 PM 10:13:45 PM 10:14:20 PM 10:14:55 PM 10:15:3W0 PM 10:16:05 PM 10:16:0 PM 10:17;15 pM 


图 4-9 ”activity chart 显 示 了 执行 特定 SQL 语句 时 经 历 了 特定 等 待 事件 的 模块 
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无 论 你 能 否 访问 Enterprise Manager，Oracle 都 提供 了 一 个 称 为 ASH Report 的 功能 来 从 ASH 中 抽取 
数据 而 不 需要 写 SQL 语 句 。 它 的 目的 是 针对 选择 的 时 间 段 ， 根 据 若 干 维度 生成 聚合 信息 ， 生 成 的 文件 
可 以 是 文本 文件 或 HTML 文 件 。 此 外 ， 也 可 以 选择 性 地 限制 分 析 特 定 的 会 话 、SQL 语 句 、 等 待 级 别 、 
服务 、 模 块 、 动 作 、 客 户 端 ID 或 PL/SQL 访 问 点 。 可 以 使 用 Enterprise Manager 或 直接 在 SQL*Plus 里 执 
行 脚本 ashrpt.sql 或 ashrpti.sql 来 运行 ASH Report, 脚本 存放 在 $0RACLE_HOME/rdbms/admin 下 。 这 两 个 
脚本 的 区 别 在 于 前 者 输入 较 少 的 参数 。 特 别 是 在 执行 脚本 时 ， 你 无 法 限制 选择 特定 的 组 件 。 例 如 ， 执 
行 ashrpt.sql 脚 本 只 会 询问 生成 报告 的 类 型 ( 文本 或 HTML )、 要 分 析 的 时 间 段 和 报告 名 。 

SQL> @?/rdbms/admin/ashrpt.sql 


Enter ‘html' for an HTML report, or 'text' for plain text 
Enter value for report type: text 


Enter value for begin time: 02/12/14 22:12:30 


Enter duration in minutes starting from begin time: 
Enter value for duration: 5 


The default report file name is ashrpt 1 0212 2217.txt. To use this name, 
press <return> to continue, otherwise enter an alternative. 
Enter value for report name: 


下 面 是 上 一 个 执行 生成 的 报告 的 一 小 部 分 摘录 ( 完整 的 报告 请 查看 文件 ashrpt 1 0212_ 
2217.txt )。 
口 关于 报告 的 一 般 信息 : 


Analysis Begin Time: 12-Feb-14 22:12:30 
Analysis End Time: 12-Feb-14 22:17:30 
Elapsed Time: 5.0 (mins) 
Begin Data Source: V$ACTIVE SESSION HISTORY 
End Data Source: V$ACTIVE SESSION HISTORY 


Sample Count: 4,583 
Average Active Sessions: 15.28 
Avg. Active Session per CPU: 3.82 


Report Target: None specified 


口 top 等 待 事件 : 


Avg Active 
Event Event Class % Event Sessions 
db file sequential read User I/0 65.94 10.07 
log file sync Commit 14.42 2.20 
CPU + Wait for CPU CPU 5.59 0.85 
write complete waits Configuration 1.07 0.16 
口 被 引擎 分 解 的 活动 : 
Avg Active 
Phase of Execution % Activity ~ Sessions 
SQL Execution 72.:34 11.05 


PLSQOL Execution 1.46 0.22 
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D top SQL 语句 和 top wait event ( 这 里 只 显示 了 前 两 个 ， 报 告 里 包含 了 5 个 ): 


Sampled # 
SQL ID Planhash of Executions % Activity 
Event % Event Top Row Source % RwSrc 
C13smabrkr27c 569677903 1005 21.99 
db file sequential read 21.32 TABLE ACCESS - BY INDEX ROWID 15.64 


SELECT PRODUCTS.PRODUCT ID, PRODUCT NAME, PRODUCT DESCRIPTION, CATEGORY ID, WEIG 
HT_CLASS, WARRANTY PERIOD, SUPPLIER ID, PRODUCT_ STATUS, LIST PRICE, MIN PRICE, C 
ATALOG _URL, QUANTITY ON HAND FROM PRODUCTS, INVENTORIES WHERE PRODUCTS. CATEGORY _ 
ID = :B3 AND INVENTORIES. PRODUCT ID = PRODUCTS.PRODUCT ID AND INVENTORIES.WAREHO 


Oyaso1lu2p9ch4 N/A 382 8.34 
db file sequential read 7.92 ** Row Source Not Available ** 7.92 
INSERT INTO ORDER ITEMS(ORDER ID, LINE ITEM ID, PRODUCT ID, UNIT_ PRICE, QUANTITY 
) VALUES (:B# , :B83 s :B2 ; :BI ; 1) 


4.2.8 SQL 语句 统计 信息 


在 父 级 别 与 子 级 别 上 ， 分 别 ee gn oe ee re 与 SQL 语句 关联 的 游标 的 信息 
此 外 ， 父 级 别 的 性 能 统计 数据 也 可 以 在 v$sqlstats 视 图 中 查 到 。 管 vgsqlarea 和 vsq1 视 图 提供 了 更 
多 的 信息 ( 或 者 说 更 多 的 列 )， a re 首先 , 它 会 保留 更 多 的 数据 ， 
因此 即便 是 从 库 缓 存 中 交换 出 的 游标 也 可 能 会 在 v$sqlstats 视 图 中 查询 到 。 其 次 ,访问 v$sqlstats 视 
图 需要 更 少 的 资源 。 由 于 这 些 动态 性 能 视图 的 列 太 多 ( 例如， 在 10.2.0.5 版 本 中 v$sql 视 图 有 72 列 ， 在 
12.1.0.1 版 本 中 该 视图 有 91 列 ), 这 里 不 可 能 一 一 列举 ( 更 多 信息 请 参考 Oracle Database Reference 手 册 )。 
以 下 是 可 以 从 v$sql 视 图 中 获取 的 与 性 能 关系 最 密切 的 信息 及 该 信息 所 在 的 列 。 

口 游标 的 标识 (address、hash_value、sql id 和 和 child_number )。 

口 与 游标 关联 的 SQL 语句 的 类 型 ( command type ) 和 SQL 语 句 的 文本 ( sql_text 中 的 前 1000 个 字 

符 和 sql fulltext 中 的 全 部 文本 )。 

口 用 于 打开 硬 解 析 游 标的 会 话 的 服务 ( service )、 用 于 硬 解析 的 schema ( parsing_schema_name 
和 parsing_schema_id ) 以 及 在 硬 解 析 期 间 已 到 位 的 会 话 属性 ( module 和 action )。 

口 如 果 SQL 语 句 是 从 PL/SQL 执 行 的 ， 那 么 该 信息 是 ，PL/SQL 程 序 的 ID 和 SQL 语句 所 在 的 行 号 
( program id 和 program line# )。 

口 已 发 生 的 硬 解析 的 数量 ( loads )、 游 标 失效 的 次 数 (invalidations )、 发 生 第 一 次 和 最 后 一 
硬 解析 的 时 间 ( first_ load time 和 last load time )、 存 储 的 outline category 的 名 (outline_ 
category )、SQL profile ( sql_profile )、SQL patch ( sql_patch )、 生 成 执行 计划 期 间 所 使 用 的 SQL 
了 baseline ( sql_plan_baseline )， 以 及 与 游标 相关 联 的 执行 计划 的 散 列 值 (plan_hash_value )。 

已 经 完成 的 解析 、 执 行 和 获取 调用 的 数量 ( parse_calls 、executions 和 fetches ) 以 及 已 处 理 的 
行 数 ( rows_processed )。 对 于 查询 来 说 , 该 信息 是 , 已 获取 所 有 行 的 次 数 (end_of_fetch_count )。 

口 用 于 处 理 的 总 DB time ( elapsed time ), 花 在 CPU 上 的 时 间 ( cpu_time ) 或 用 来 等 待 属于 应 用 、 
并 发 .集群 和 用 户 WO 等 待 级 别 的 事件 的 时 间 ( application wait time、concurrency_wait time、 
cluster wait time 和 user io wait time ), 以 及 PL/SQL 引 警 和 Java 虚 拟 机 已 完成 的 处 理 的 数量 
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( plsql exec time 和 java_exec time )。 所 有 值 的 单位 都 是 微 秒 。 
口 已 经 完成 的 逻辑 读 、 物 理 读 、 直 接 写 和 排序 的 数量 ( buffer gets、 disk reads、 direct writes 
和 sorts )。 


4.2.9 实时 监控 


鉴于 上 一 节 介 绍 的 动态 性 能 视图 只 能 提供 关于 游标 的 累积 统计 数据 ,实时 监控 能 提供 游标 执行 期 
间 的 信息 。 有 两 个 重要 的 执行 细节 需要 注意 。 第 一 ， 实 时 监控 提供 的 是 执行 期 间 的 信息 。 换 句 话 说， 
你 不 需要 等 待 执行 结束 就 能 看 到 想 要 的 信息 。 第 二 ， 实 时 监控 的 信息 是 根据 游标 独立 存放 的 。 因 此 ， 
即使 游标 已 经 被 刷 出 库 缓 存 ， 相 关 信 息 可 能 还 可 以 访问 到 。 在 某 种 程度 上 ， 实 时 监控 的 目的 和 ASH 很 
像 。 实际 上 ，ASH 提 供 的 是 活动 会 话 状态 的 历史 信息 ， 而 实时 监控 提供 的 是 游标 执行 的 历史 信息 。 

注意 ， 要 使 用 实时 监控 ， 必 须 有 Tuning Pack 选 件 的 许可 。 此 外 ， 实 时 监控 只 在 11.1 版 本 之 后 才 开 
始 支持 。 如 果 初 始 化 参数 control management pack_access 没 有 设置 成 diagnostic+ttuning, 那么 实时 监 
控 是 无 效 的 。 

由 于 监控 所 有 的 执行 是 无 意义 的 ， 因 此 数据 库 引擎 会 默认 在 以 下 三 种 情况 下 局 用 监控 。 

口 CPU 和 磁盘 LO 的 时 间 总 和 超过 了 5 秒 的 执行 。 

口 使 用 并 行 处 理 的 执行 。 

口 通过 指定 monitor hint 显 式 启 用 实时 监控 的 SQL 语 句 ( 同样 可 以 使 用 no_monitor hint 来 显 式 禁 用 

实时 监控 )。 


警告 ”在 以 下 两 种 情况 下 , 数据 库 引 党 会 对 特定 执行 自动 禁用 实时 监控 。 第 一 , 执行 计划 超过 300 行 
第 二 ,监控 的 数量 超过 了 每 颗 CPU 上 20 个 并 行 执 行 。 要 想 越过 这 些 限制 ,你 可 以 分 别 加 大 未 公 
开 的 初始 化 参数 _sqlmon_max_planlines 和 _sqlmon_max_plan 的 默认 值 。 由 于 加 大 默认 值 会 导致 
更 高 的 CPU 和 内 存 消耗 ， 在 没有 谨慎 测试 修改 前 ， 不 要 把 它们 设置 成 过 高 的 值 。 


要 查看 当前 监控 的 是 哪个 操作 ， 可 以 直接 查询 v$sql_monitor 视 图 或 执行 dbms_sqltune 包 下 的 
report sql monitor _ list 函数 。 对 于 每 个 受 监控 的 执行 ,数据库 引 擎 都 会 提供 基本 信息 ， 比 如 操作 是 
否 仍 在 执行 ,与 受 监控 操作 相关 的 SQL 语句 ， 以 及 像 DB time 使 用 率 这 样 的 关键 性 能 指标 。 图 4-10 显 示 
由 Enterprise Manager 提 供 的 部 分 信息 。 


Status Duration SQLID User Parallel Database Time | 10 Requests | Start | 
3 | :oo | Skwfj03dc3dp SOE N27 ‖s.1e2 10:59:17 AM 
2 i 0 I lil 
w D's fmis40a43y26 SOE 好 s 用 7 sss 10:39:41 AM 
i" m2 :of 动 。 国 罗 :sn 最 前 ?or 10:30:40 AM 
eg i 17.7ms dmdh8rprémxs SOE | 17.7ms i 1 10:55:14 AM 


图 4-10 ”监控 操作 列表 
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要 想 查 看 所 有 实时 监控 获取 到 的 信息 , 你 需要 使 用 dbms_sqltune 包 下 的 report_ sql _monitor 函 数 生 
成 报告 。 这 样 的 操作 可 以 在 任何 能 够 执行 SQL 语句 的 工具 里 实现 ， 在 Enterprise Manager 的 几 个 页 面 里 
也 可 以 实现 ( 例如，Performance 菜 单 下 的 SQL Monitoring 连 接 )，report sql_monitor 函 数 包含 若干 输 
和 变量 并 输出 一 个 包含 报告 的 CLOB。 有 些 输入 变量 用 来 指定 监控 信息 ， 还 有 的 用 来 指定 报告 的 格式 
和 显示 的 数据 。 例 如 ，sql_id 参 数 用 来 指定 需要 显示 的 SQL 语句 信息 〈 如 果 指 定 为 NWLL， 那 么 会 显示 
最 后 一 次 操作 )，type 参 数 用 来 指定 生成 报告 的 格式 ( 建议 最 好 用 active; text 、html 和 xml 同 样 也 可 
以 )。 以 下 查询 摘自 report_sql_monitor.sql 脚 本 ， 展 示 如 何 生成 报告 


SELECT dbms sqltune.report sql _ monitor(sql_ id => '5kwfj03dc3dp1', 
type => “active') 


FROM dual 

在 大 多 数 情况 下 ， 报 告 包含 了 所 有 你 需要 理解 的 信息 。 对 于 一 个 活动 报告 来 说 ( text 和 html 格 式 
的 报告 提供 的 信息 较 少 )， 会 提供 如 下 信息 。 

口 执 行 的 基本 信息 与 关键 性 能 指标 的 摘要 ( 图 4-11 ) 


Overview : Es 
SQLID Skwfjo3dc3dp1 国 Time & Wait Statistics 
Executon Started Fri Feb 14, 2014 10:59:17 AM | ”Duratcn 3.0 | 


_ | 
Last Refresh Time Fr Feb 14, 2014 10:59:53 AM | Database Time P| 35.35 
Execution ID 16777216 | 
User SOE | PLSQL & Java 0us 


| 


图 4-11 ”监控 操作 的 概述 信息 
口 执行 计划 ， 包 含 操作 级 别 的 性 能 指标 ( 图 4-12 ) 


val Rows Ti Timeline(365) ， IO Requests| [activity 9% 


Sd 


1 199 
上 日 SORT GROUP BY 1 199 a 
日 -NESTED LOOPS OUTER 1 1,000 t 
日 HASH JOIN 1 1,000 | TOE 
| -TABLE ACCESS FULL PRODUCT_ INFO 1 1000 i 
日 viEw VW_GBEC.9 1 1.000 , | 
| 日 HASH GROUP BY 1 L000 La 20 
日 HASH JOIN 1 18M WIN 
TABLE ACCESS FULL ORDERS 1 6,156K [First Active: 205; Duration: 16s: 
TABLE ACCESS FULL ORDER_ITEMS 1 32M Bi i 0 


0 


和 


INDEX UNIQUE SCAN PRD DESC_PK 


图 4-12 ”监控 操作 的 执行 计划 
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口 显示 CPU 使 用 和 执行 期 间 经 历 的 等 待 事件 的 活动 示意 图 ( 图 4-13 ) 


jve SesSi 
Ld bd 
一 一 ad 


置 ”CPU (cr wait for CPU) 
“里 冯 J drect path read 


10:59:19 AM 10:59:27 AM 10:59:35 AM 10:59:43 AM 10:59:51 AM 
图 4-13 ”监控 操作 的 活动 示意 图 
口 显示 执行 期 间 某 些 度量 值 的 改变 的 若干 图 表 ( 图 4-14 ) 


0.8| 


a 
0.4 
| 
“| 
0 
0 2 4 6 8 0 2 14 46 18 23 2 3 2»% 283 3 有 到 六 天 38 
Time (5) 
图 4-14 ”监控 操作 的 CPU 使 用 率 图 表 


要 显示 监控 操作 的 相关 SQL 语句 文本 ， 需 单 击 SQL ID 旁边 的 (i) 图 标 。 之 后 会 弹出 窗口 显示 
SQL 语 名 文本。 此外， 如果 操作 里 包含 绑 定 变量 ， 也 会 显示 绑 定 变 量 名 、 位 置 、 数 据 类 型 和 绑 定 变 
量 值 。 

报告 中 最 有 意思 的 部 分 是 Plan Statistics 表 。 有 了 它 ， 不 仅 可 以 看 到 在 操作 级 别 执行 计划 的 资源 汇 
总 ， 还 能 看 到 执行 计划 操作 完成 的 时 间 和 返回 的 行 数 。 例 如 ， 在 图 4-12 中 ， 可 以 看 到 从 执行 开始 20 秒 
后 HASH JOIN 操作 〈 鼠标 高 亮 的 那 一 行 ) 返回 了 1800 万 行 ， 并 持续 执行 了 16 秒 ( 你 可 以 把 鼠标 停 在 时 间 
线 的 条 上 显示 这 些 信息 )。 使 用 Enterprise Manager 查 看 报告 时 ， 另 一 个 重要 的 特性 是 可 以 实时 跟踪 活 
动 操作 的 执行 。 

在 Activity 表 中 针对 每 个 监控 操作 ,都 有 一 个 图 表 来 显示 CPU 使 用 率 和 执行 期 间 的 等 待 事件 .例如 ， 
图 4-13 显 示 ， 虽 然 执 行 开 始 时 花 在 CPU 上 的 大 部 分 时 间 基 本 等 同 于 直接 读 所 用 的 时 间 ， 但 在 执行 的 最 
后 ， 该 操作 全 部 仰 仗 CPU。 注 意 只 有 并 行 操作 活动 会 话 的 值 才 会 大 于 1。 

Metrics 表 显示 如 下 若干 性 能 指标 的 图 表 : CPU 使 用 率 、 磁 盘 IO 请 求 数 、 磁 盘 IO 吞 吐 量 、PGA 使 
用 量 和 临时 表 空 间 使 用 量 。 图 4-14 显 示 了 CPU 使 用 率 。 注 意 该 图 显示 的 内 容 早已 在 activity chart 里 看 到 
过 : 随 着 执行 的 增加 ，CPU 使 用 率 上 升 。 

Plan 表 显 示 包 括 由 查询 优化 器 估量 的 所 有 信息 在 内 的 执行 计划 。 例 如 ， 你 可 以 通过 它 查 询 到 哪个 
执行 计划 操作 用 到 了 谓词 推 人 。 最 后 ， 针 对 并 行 操作 ，Parallel 表 显示 涉及 执行 的 每 个 进程 的 繁忙 度 。 
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复合 数据 库 操作 


在 11.1 版 本 中 , 实时 监控 只 能 监控 SQL 语句 ,因此 有 时 也 被 叫 作 实时 SQL 监控 。 从 11.2 版 本 开始 ， 
此 特性 也 开始 支持 PL/SQL 块 。 最 终 ， 从 12.1 版 本 开始 ， 使 用 复合 数据 库 操作 可 以 把 数 个 SQL 语句 或 
PL/SQL 块 当 作 一 个 操作 来 处 理 。 换 和 句 话说， 可 以 把 实时 监控 扩展 成 对 业务 有 意义 的 用 户 自 定义 操 
作 。 例如， 使 用 复合 数据 库 操作 来 定义 批 处 理 任务 执行 的 所 有 SQL 语 句 都 作为 单个 操作 受到 监控 
要 定义 复合 数据 库 操作 ， 你 需要 为 监控 的 任务 起 名 。 有 以 下 三 种 方法 可 以 实现 
口 Generic: 使 用 dbms_sql_monitor 包 ， 具 体 说 是 begin_operation 和 end_operation 函 数 来 明确 指 
定 操 作 的 开始 和 结束 。 这 个 方法 可 以 在 任何 开发 语言 中 使 用 ， 
口 Java: 使 用 java.sql.Connection 接 口 的 setClientInfo 方 法 。 这 个 技术 只 对 JDBC 4.1 及 之 后 的 
版 本 有 效 。 
口 OCI: 使 用 OCIAttrSet 函 数 设置 0CI ATTR_DBOP 会 话 属性 


4.3 使 用 Diagnostics Pack 和 Tuning Pack 进行 分 析 


要 使 用 Diagnostics Pack 做 分 析 ， 建 议 使 用 Enterprise Manager 的 performance 页 ( 无 论 使 用 的 是 
Database Control 、Grid Control 还 是 Cloud Control )。 因此 这 一 部 分 的 结构 和 例子 都 基于 Enterprise 
Manager。 注 意 ， 该 部 分 的 所 有 例子 也 都 适用 于 Cloud Control 12.1.0.3.0 版 本 的 Enterprise Manager 页 。 
万 一 你 用 不 了 Enterprise Manager， 我 也 会 介绍 一 些 脚 本 ， 这 些 脚 本 使 用 动态 性 能 视图 来 生成 类 似 的 信 
息 ， 你 可 以 使 用 SQL*Plus 来 执行 相同 的 分 析 。 强 调 一 下 ， 如 果 使 用 Enterprise Manager， 分 析 会 更 简单 
一 些 。 不 使 用 Enterprise Manager 的 唯一 优势 是 可 以 非常 灵活 方便 地 访问 到 所 有 可 用 数据 。 


4.3.1 数据 库 服务 器 负载 


想 要 获得 数据 库 服务 器 的 负载 情况 , 可 以 查看 Performance 首 页 的 第 一 个 图 表 。 该 图 表 会 显示 实时 
或 历史 数据 。 由 于 本 章 的 目标 是 实时 分 析 性 能 问题 (或 刚 发 生 过 的 )， 这 里 默认 使 用 实时 数据 。 因 此 ， 
-小 时 之 内 的 数据 都 是 可 用 的 。 注 意图 表 显 示 的 实时 数据 同样 可 以 通过 v$metric_history 视 图 查 到 。 

当 监控 数据 库 服务 器 负载 情况 时 ， 不 仅 要 查看 数据 库 服务 器 是 否 是 CPU bound ( 换 句 话说 ， 是 否 
所 有 的 CPU 内 核 都 被 充分 利用 )， 同 时 也 要 关注 消耗 大 量 CPU 时 间 的 进程 是 否 与 数据 库 实 例 有 关 。 图 
4-15 是 一 个 CPU bound 数 据 库 服务 器 的 例子 , 大约 持 续 了 5 分 钟 。 然 而 数据 库 实例 的 后 台 和 前 台 进 程 经 
常 只 使 用 两 个 CPU 内 核 。 实际 上 ， 当 数据 库 服 务 器 是 CPU bound 时 ， 大 约 有 6 个 CPU 内 核 会 被 不 属于 数 
据 库 实例 的 进程 充分 使 用 。 因 此 在 本 例 中 ,在 五 分 钟 内 ， 有 可 能 发 生 由 于 数据 库 服 务 器 的 其 他 进程 造 
成 数据 库 引 擎 经 历 性 能 问题 。 
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TE 

12 -| 

6 -SPU Corea Fn 加 平均 负载 

| ~ 晤 Non-Database Host CPU 
0 | MN Instance Background CPU 
02:05PM 02:10PM 02:15PM 02:20PM CPU 


图 4-15 Runnable Processes 图 表 显 示 了 数据 库 服务 器 级 别 的 CPU 使 用 率 和 平均 负载 


遗憾 的 是 ， 直 到 11.1 版 本 ( 包含 11.1 版 本 )，Runnable Processes 图 表 仅 能 显示 平均 负载 ( 在 Linux 
数据 库 服务 器 上 , 该 值 与 /process/10adavg 的 值 相同 ), 这 是 因为 在 之 前 的 版 本 中 相关 值 的 度量 不 可 用 。 


警告 ” 当 数 据 库 服务 器 配置 使 用 多 线程 并 行 处 理 的 CPU 时 ， 初 始 化 套数 cpu_count 和 v$osstat 视 图 的 
NUM_CPUS 值 都 会 被 设 成 总 线程 数 。 因 此 ， 在 Runnable Process 图 表 里 红线 代表 线程 数 ， 而 不 是 
CPU 内 核 数 ( 如 上 所 述 )。 注 意 使 用 线程 数 来 评估 数据 库 是 否 为 CPU bound 会 造成 误导 。 实 际 
上 ，100% 使 用 所 有 线程 是 不 可 能 的 。 同 时 注意 虚拟 化 也 有 同样 的 问题 。 


如 果 无 法 使 用 Enterprise Manager， 可 以 使 用 host_load_hist.sql 脚 本 来 显示 与 图 4-15 相 同 的 信息 。 
注意 ， 脚 本 不 需要 参数 。 度 量 会 显示 一 个 小 时 内 所 有 可 用 的 数据 。 以 下 是 脚本 输出 的 一 段 节选 : 
SQL> @host load hist.sql 


BEGIN TIME DURATION DB FG CPU DB BG CPU NON DB CPU OS_ LOAD NUM CPU 


se Eg 9 RR 


14:05:00 60.10 L371 0.03 0.03 4.09 8 
14:06:00 60.08 1.62 0.03 0.04 维和 3 8 
14:07:00 59.10 1.89 0.03 0.04 4.96 8 
14:08:00 60.11 1.93 0.03 0.03 5.29 8 
14:09:00 60.09 1.73 0.03 0.59 4.60 8 
14:10:00 60.10 1.57 0.02 3.64 7.50 8 
14:11:00 60.16 4s15 0.02 6.60 11.82 8 
14:12:00 60.11 1.21 0.02 6.60 13.77 8 
14:13:00 60.28 Ll 0.02 6.62 15.30 8 
14:14:00 59.24 1.19 0.02 6.55 14.06 8 
14:15:00 60.09 1.59 0.04 0.18 9.19 8 
14:16:00 60.09 Lady 0.03 0.03 7.88 8 
14:17:00 60.09 1.72 0.03 0.04 5.45 8 
14:18:00 60.11 1.87 0.03 0.03 5.28 8 
14:19:00 60.09 1.77 0.03 0.03 5.54 8 
14:20:00 60.08 1.72 0.03 0.04 4.83 8 


4.3.2 ”系统 级 别 分 析 


如 果 继 续 系 统 级 别 分 析 ， 应 该 从 Top Activity 页 面 开 始 。 我 不 建议 使 用 Performance 主 页 ， 特 别 是 
Average Active Session 图 表 ， 因 为 只 有 在 单个 等 待 级 别 消耗 了 大 部 分 响应 时 间 时 ， 这 个 页 面 的 挖掘 功 
能 才能 快速 定位 性 能 问题 。 
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提示 “如 果 可 以 使 用 ASH Analytics， 则 应 该 用 它 代 替 Top Activity 页 面 。 在 某 些 情况 下 ， 更 灵活 地 选 
取 时 间 段 分 析 、 添 加 过 滤器 以 及 根据 众多 维度 汇总 数据 ， 可 以 获得 更 简单 详细 的 分 析 


Top Activity 页 面 会 显示 实时 和 历史 数据 。 由 于 本 章 的 目标 是 实时 分 析 性 能 问题 ( 或 刚 发 生 过 的 )， 
这 里 默认 使 用 实时 数据 。 因此， 一 小 时 之 内 的 数据 都 是 可 用 的 。 请 注意 ，Top Activity 页 面 显示 的 实时 
数据 同样 可 以 通过 v$active session history 视 图 查 到 

Top Activity 页 面 会 提供 以 下 三 组 数据 

口 Activity 图 表 ( 图 4-16 ) 显示 最 后 一 小 时 的 数据 。 它 还 会 把 DB time 分 成 CPU 使 用 率 和 等 待 级 别 


14 FE 7 
12 时 Other 
是 Qoeueing 
10 于 Network 
Maximum CPU 于 Administrative 
和 和 国 Configuration 
辣 ” 6 夯 Commit 
拭 面 Application 
4 图 Concurrency 
时 System I/O 
2 国 UserI/O 
0 Scheduler 
07:05PM 07:10PM 07:15PM 07:20PM “” 电 CPU + CPU Wait 


图 4-16 Activity 图 表 显 示 系 统 级 别 的 CPU 使 用 率 和 等 竺 级别 


口 Top SQL 表 ( 图 4-17 )， 显示 在 activity 图 表 中 所 选择 的 五 分 钟 间 隔 里 ,最 耗 时 的 SQL 语 句 。 每 条 
SQL 语 句 会 显示 其 总 活动 百分比 以 及 SQL ID 


Select | Activity (%) 号 SQLID SQL Type | 
[4.56 ci3smarkr27c SELECT 
E20-63 Sdq0vimngj7t SELECT 


| E125 mhk2m2702ua0g SELECT 
器” mm 11.95 bymb3ujkr3ubk INSERT 
] mm 3.32 0yas0102p9ch4 INSERT 
EN 5.57 obzhqhhj9mpaa INSERT 
| 5.94 Sz3542ffmp562 SELECT 
器“ ;337 Smddtskt45rg3 UPDATE 
| Es fgu2k84v884y7 UPDATE 
六 .83 Ow2qpuc6u2zsp PL/SQL EXECUTE 


图 4-17 Top SQL 表 显示 系统 级 别 上 最 耗 时 的 SQL 语 句 


口 Top Session 表 ( 图 4-18 )， 显 示 在 activity 图 表 中 所 选择 的 五 分 钟 间 隔 里 ， 最 耗 时 的 会 话 
会 话 会 显示 其 总 活动 百分比 以 及 会 话 信 息 (ID 、 用 户 名 以 及 打开 它 的 程序 ) 
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活动 ( 哆 抑 会 话 ID | 用 户 名 “| 程序 | 
1 2 SOE DBC Thin cient 
I 163 :< soE JDBC Thin Cient 


mm 1 135 SOE ec 
=e 156 SOE JDBC Thin Cient 
1! 1 OE ne 
JR 1 127 SOE JDBC Thin Client 


Lo ET 
ER 1.48 162 SOE JDBC Thin Client 
mm 1 68 SOE DOC Th Cent 
TEST 224 SOE JDBC Thin Client 

Total Samole Count: 3.103 


图 4-18 Top Sessions 表 显示 最 耗 时 的 会 话 


Activity 图 表 有 两 个 目的 。 首先, 它 可 以 让 你 从 数据 库 引 擎 的 角度 了 解 发 生 了 什么 。 例 如 ,通过 图 
4-16， 你 不 仅 可 以 知道 平均 活动 会 话 数 为 3~13〈 由 于 CPU 数 为 8， 因 此 数据 库 引擎 属于 中 度 负载 )， 还 
可 以 知道 用 户 IO 等 待 级 别 占用 了 大 部 分 DB time。 其 次 ， 你 可 以 使 用 它 来 显示 五 分 钟 间隔 内 你 想 要 查 
看 的 详细 数据 库 负 载 信 息 。 因 此 ， 如 果 你 没有 对 某 一 特定 时 刻 进行 分 析 ， 通 常 可 以 选择 活动 会 话 数 最 
多 的 那个 时 间 段 。 换 句 话说 ， 你 应 该 选择 负载 最 高 的 时 间 段 。 

如 果 你 无 法 使 用 Enterprise Manager， 可 以 使 用 ash_activity.sql 脚 本 来 显示 最 后 一 小 时 的 活动 率 
这 个 脚本 的 目的 是 显示 平均 活动 会 话 数 和 对 应 每 个 等 待 级 别 的 百分比 。 下 面 的 例子 是 基于 图 4-16 显 示 
的 时 间 段 产生 的 输出 结果 ( 注意 ， 脚 本 跟着 的 两 个 参数 al1， 代 表 输 出 结果 没有 限制 到 某 个 会 话 或 某 
个 SQL 语句 )， 与 图 4-16 唯 一 不 同 的 是 数据 以 分 钟 为 单位 聚合 。 


SQL> @ash activity.sql all all 
TIME AvgActSes CPU% USTIO% SysI0% Conc% Appl% Commit% Config% Admin% Net% Queue% Other% 


19:04 3.8 6.2 93.8 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:05 3.6 8.0 92.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:06 5.6 4.8 95.2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:07 3.4 1T9 1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:08 6.0 0 92:5 0.0 2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:09 7 6.9 93.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:10 11.2 3 303 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:11 10.4 4.5 95.5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:12 10.9 259 9711 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:13 9.8 G5 93:5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:14 9.2 358 96.2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19515 8.6 SE 94.8 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:16 8.0 4.6 95.4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:17 7.6 5.1 94.9 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:18 6.1 4.4 95.6 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:19 Se 5.0 95.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:20 6.0 7 和 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:21 4.8 4:5 95.5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:22 4.9 5.7 94.3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
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一 旦 选择 了 你 想 要 关注 的 五 分 钟 间 隔 ， 就 应 该 去 Top SQL 页面 查看 相应 信息 ( 图 4-17 )。 如 果 显 示 
少数 SQL 语句 占用 了 大 百分比 的 活动 率 ( 比如 , 单个 SQL 语句 的 活动 率 达 到 了 两 位 数 )， 就 能 定位 到 需 
要 进一步 分 析 的 SQL 语句 。 例 如 ， 根 据 图 4-17， 有 7 个 查询 占用 了 90% 多 的 活动 率 。 因 此 ， 为 了 降低 系 
统 负载 ， 应 该 关注 这 些 语句 。 

要 想 不 使 用 Enterprise Manager 显 示 图 4-17 的 数据 , 可 以 使 用 ash_top_sqls.sql 脚 本 。 注意, 该 脚本 
需要 三 个 输入 参数 。 前 两 个 参数 用 来 指定 显示 数据 的 时 间 段 ( 本 例 是 开始 和 结束 的 时 间 戳 )。 第 三 个 
参数 指定 具体 会 话 ( 这 里 指定 all )。 以 下 输出 的 数据 与 图 4-17 显 示 的 相同 。 


SQL> @ash top sqls.sql 2014-02-04 19:10:02.174 2014-02-04 19:15:02.174 all 


Activity% DB Time CPU% UsrI0% Wait% SQL Id SQL Type 
24.6 744 4.2 95.8 0.0 ci3sma6rkr27c SELECT 
20.6 625 0.3 99.7 0.0 8dqovimjngj7t SELECT 
12.4 377 1.1 98.9 0.0 7hk2m2702ua0g SELECT 
12.0 362 1.9 98.1 0.0 bymb3ujkr3ubk INSERT 

8.3 252 3.6 96.4 0.0 Oyas01u2p9ch4 INSERT 
6.9 208 1.4 98.6 0.0 Obzhqhhj9mpaa INSERT 
5.9 180 2.2 97.8 0.0 8z3542ffmp562 SELECT 
3 102 5.9 94.1 0.0 5mddtSkt45rg3 UPDATE 
2.4 74 2.7 97.3 0.0 f9u2k84v884y7 UPDATE 
0.8 25 100.0 0.0 0.0 Ow2qpuc6u2zsp PL/SQL EXECUTE 


如 果 没 有 突出 的 SQL 语句 ， 那 么 显然 高 活动 率 是 由 很 多 条 SQL 语句 造成 的 。 因 此 ， 这 表明 要 想 提 
升 性 能 应 该 主要 修改 应 用 。 遇 到 类 似 情 况 时 ， 建 议 查 看 其 他 维度 的 活动 率 聚合 。 默 认 情 况 下 ，Top 
Activity 页 面 显示 Top Sessions 表 ( 图 4-18 )。 但 是 在 这 张 表 顶部 的 下 拉 列 表 里 ， 可 以 选择 以 其 他 维度 对 
数据 进行 聚合 ， 如 Top Services 、Top Modules 、Top Actions ( 图 4-19 ) 和 Top Clients。 有 时 这 对 找到 造 
成 高 负载 的 应 用 组 件 或 客户 端 很 有 帮助 。 请 注意 ， 有 一 些 维度 只 有 在 分 析 的 应 用 正确 设置 了 第 2 章 介 
绍 的 会 话 属性 后 ， 才 会 提供 有 用 的 信息 。 


Activity (%) 有 Service ”|Module Action | 


EE 24.01 DEM11203.antognini.ch New Order getProductDetailsByCategory 
EE 23.78 DBM11203.antognini.ch New Order 

E11. 57 DBM11203.antognini.ch Process Orders 

EE 10.22 DBM11203.antognini.ch Browse Products getCustomerDetails 
NN 3.35 DEM11203.antognini.ch New Order getCustomerDetails 

mm 6.30 DBM11203.antognini.ch New Customer 

Em 3.37 DBM11203.antognini.ch New Order getProductQuantity 

因 1.64 SYSSBACKGROUND 

国 1.61 DBM11203.antognini.ch Browse and Update Orders getCustomerDetails 

1:7 DBM11203.antognini. 中 


Toral Sample Count: 3,103 
图 4-19 Top Actions 表 显示 根据 service 、module 和 action 聚 合 的 最 耗 时 组 件 信息 
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注意 ”Enterprise Manager 显 示 的 Total Sample Count 值 代表 创建 图 表 时 使 用 的 历史 活动 会 话 取 样 数 ， 例 
如 ， 图 4-18 使 用 了 3103 个 取样 。 


当 考 虑 到 像 Top Sessions 或 Top Actions 表 那样 显示 活动 率 时 ， 同 样 需要 查找 占用 大 量 活动 率 的 组 
件 。 例如 , 虽然 根据 图 4-18 没 有 哪个 会 话 的 活动 率 超过 2%, 但 图 4-19 显 示 少 数 modle/action 造 成 了 大 部 
分 负载 ， 因 此 除了 Top SQL 表 指出 的 部 分 外 ， 你 或 许 也 应 该 检查 一 下 这 些 module/action。 

要 想 不 使 用 Enterprise Manager 来 根据 特定 维度 显示 数据 聚合 ， 可 以 使 用 如 下 脚本 中 的 一 个 : 
ash top sessions.sql, ash top services.sql、 ash top modules.sql、 ash top actions.sql、 ash top_ 
clients.sql、 ash top files.sql、 ash top objects.sql 和 ash_top_plsql.sql。 维度 信息 已 经 明确 写 在 
脚本 名 里 。 注意 所 有 脚本 都 需要 两 个 输入 参数 ( 开始 时 间 惟 和 结束 时 间 戳 ) 来 指定 显示 数据 的 时 间 段 。 
以 下 两 个 例子 显示 的 输出 是 由 ash_top_sessions.sql 和 ash_top actions.sql 脚 本 生成 的 ， 分 别 等 同 于 
图 4-18 和 图 4-19: 


SQL> @ash top sessions.sql 2014-02-04 19:10:02.174 2014-02-04 19:15:02.174 


Activity% DB Time CPU% UsrI0% Wait% Session Id User Name Program 


Fs 52 9.6 90.4 0.0 232 SOE JDBC Thin Client 
yp 52 3.8 96.2 0.0 16 SOE JDBC Thin Client 
1.6 49 4.1 95.9 0.0 136 SOE JDBC Thin Client 
| 48 6.3 93.8 0.0 156 SOE JDBC Thin Client 
1,5 dy 3 6 Zt 170 SOE JDBC Thin Client 
41:5 46 10.9 89.1 0.0 127 'SOE JDBC Thin Client 
1.5 46 6.5 93.5 0.0 74 SOE JDBC Thin Client 
5 a46 B87 89 22 162 SOE JDBC Thin Client 
| 4 2 _ I .Ot 68 SOE JDBC Thin Client 
上 45 8.9 91.1 0.0 77 SOE JDBC Thin Client 


SQL> @ash top actions.sql 2014-02-04 19:10:02.174 2014-02-04 19:15:02.174 


Activity% DB Time CPU% UsrI0% Wait% Module Action 
24.0 745 4.3 95.7 0.0 New Order getProductDetailsByCategory 
23.8 738 6.0 94.0 0.0 New Order 
14.6 452 1.5 98.5 0.0 Process Orders 
10.2 317 0.0 100.0 0.0 Browse Products getCustomerDetails 
8.3 259 1.2 98.8 0.0 New Order getCustomerDetails 
6.8 211 2.8 97.2 0.0 New Customer 
5.9 182 3.3 96.7 0.0 New Order getProductQuantity 
1.6 这 3763 3.9 58.8 
1.6 50 0.0 100.0 0.0 Browse and Update Orders getCustomerDetails 
0.8 24 45.8 0.0 54.2 


4.3.3 ”会 话 级 别 分 析 


如 果 执 行 会 话 级 别 分 析 ， 出 发 点 应 该 基于 会 话 是 否 还 存在 。 如 果 会 话 存 在 ， 则 可 以 在 Performance 
菜单 下 的 Search Sessions 菜 单 中 搜索 到 会 话 信息 。 另 外 , 也 可 以 在 Top Activity 页 面 , 特别 是 Top Sessions 


4.3 


表 中 找到 对 应 的 Session ID 链接 。 
会 话 级 别 的 活动 率 页 面 提供 了 以 下 三 组 数据 。 

口 Activity 图 表 ( 图 4-20 ) 显示 CPU 与 等 待 事件 分 别 占用 的 DB time。 它 会 显示 一 个 小 时 的 数据 。 

如 果 活 动 率 为 0, 代表 会 话 是 空闲 状态 。 如 果 活 动 率 达到 100%， 则 代表 会 话 完 全 忙于 处 理 用 户 


调用 。 


100 


80 


20 


07:;09PM 


图 4-20 


07:14PM 


07:19PM 


会 话 级 别 活动 率 图 表 显 示 单 独 会 话 的 CPU 使 用 率 和 等 待 事件 
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log file sync 

db file parallel read 
read by other session 
db file sequential read 
CPU Used 


口 Active session history aggregated data ( 图 4-21 ) 显示 了 在 activity 图 表 中 所 选择 的 5 分 钟 间 隔 里 最 
耗 时 的 SQL 语句 。 对 于 每 条 语句 ， 会 给 出 总 活动 率 、SQL ID、 执 行 计划 的 散 列 值 和 一 些 会 话 


SQL Command | Plan Hash Value | Module 


Activity (%) 可 SQLID 

[ER 23.08 c13sma6rlr27c< SELECT 
13. 46 bymb3ujkr3ubk INSERT 
[Ec 13.46 8dq0vlmjngj7t SELECT 
es 11.54 Oyas01lu2p9ch4 INSERT 
[en 9.62 8dq0vlmjngj7t SELECT 
a 5.77 8z3542ffmp562 SELECT 
国 国 3.85 Druh367af7gbw SELECT 
加 二 3.35 f9u2k8 4v384y7 UPDATE 
医 强 3.85 Thk2m2702ua0g SELECT 
WE 3.85 obzhqhhj9mpaa INSERT 

图 4-21 


2583456710 
494735477 
900611645 
0 
900611645 
1655552467 
3322340634 
1628223527 
1278617784 
0 


New Order 

New Order 

New Order 

New Order 

Browse Products 

New Order 

Browse and Update Orders 
Process Orders 

Process Orders 

New Customer 


Active session history aggregated data 显 示 会 话 级 别 上 最 耗 时 的 SQL 语句 


口 Active session history raw data ( 图 4-22 ) 显示 了 在 activity 图 表 中 所 选择 的 五 分 钟 间隔 里 ， 取 样 


的 详细 信息 。 
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Sample Tme WwW |SQLD SQL Type | Plan Hash Value | Wait Event P1 Value | P2 Yalue | P3 Value | Time Waited (mhu s) 
2/4114 7:14:54PM Oyiprvxqc2ra9 SELECT 302912750 CPU 

2/4/14 7:14:45PM 0bzhqhhj9mpaa INSERT 0 db fille sequential read 5 3652838 1 14859 
2/4/14 7:14:44PM 8z3542ffmp562 SELECT 1655552467 bfile seguential read 5 1084446 1 3923 
2/4/14 7:14:24PM 7hk2m2702ua0g SELECT 1278617784 db fle sequential read 5 3426419 1 12010 
2/4/14 7:14:22PM 8z3542ffmp562 SELECT 1655552467 dbfile seguentialread 5 1087383 1 7257 
2/41147:14:16 PM bymb3ujr3ubk INSERT 494735477 dbfie sequentialread 5 3427835 1 15603 
214114 7:14:03PM bymb3ujr3ubk INSERT 494735477 efile seguential read 5 234809 1 34997 
2/4/14 7:14:01PM Thk2m2702ua0g SELECT 1278617784 dbfile sequentialread 5 10221 1 33044 
2/4/14 7:14:00 PM 0yas01u2p9dh4 INSERT 0 db fle seqguential read 5 3576201 1 78505 
2/4/14 7:13:43PM 0yas01u2p9ch4 INSERT 0 db file sequential read 5 3515548 1 6447 
214/14 7:13:42PM SmddtSkt45rg3 UPDATE 1628223527 db fle seguential read 5 3419246 1 6663 
2/4/14 7:13:36 PM 0bzhaqhhj9mpaa INSERT 0 db file seguential read 5 3653055 1 6129 
2/4f14 7:13:35PM 8dq0ylmjngj7t SELECT 900611645 db file sequential read 5 346169 1 20058 
2/4/14 7:13:22PM cl3sma6rkr27c ”SELECT 2583456710 dbfile seguentialread 5 1088402 1 7206 
2/4/14 7:13:20 PM cl3sma6rlr27c SELECT ”2583456710 db file sequential read 5 1078754 1 29743 


图 4-22 ”Active session history raw data 显 示 取 样 的 详细 信息 


会 话 级 别 分 析 与 上 一 节 介 绍 的 系统 级 别 分 析 很 像 。 唯 一 的 主要 区 别 是 ， 在 会 话 级 别 ，Enterprise 
Manager 没 有 根据 多 个 维度 聚合 数据 的 选项 。 你 关注 的 是 单独 的 会 话 ， 而 且 在 大 多 数 情况 下， 只 与 top 
SQL 语句 有 关 。 

如 果 不 能 访问 Enterprise Manager, 可 以 分 别 使 用 ash_activity.sql 和 ash_top_sqls.sql 脚 本 来 显示 
等 同 于 图 4-20 和 图 4-21 的 数据 。 请 参考 上 一 节 中 对 脚本 的 简介 。 要 使 用 它们 ， 只 需要 指定 要 分 析 的 会 
话 ID 即 可 。 可 以 查询 v$active_session_history 视 图 来 显示 图 4-22 中 的 数据 。 下 面 举例 说 明 如何 使 用 
ash_activity.sql 脚 本 来 显示 与 图 4-20 相 似 的 数据 ( 注意， 第 一 个 参数 指定 会 话 ID )。 


SQL> @ash activity.sql 232 all 


TIME AvgActSes CPU% UsrI0% SysIO% Conc% Appl% Commit% Config% Admin% Net% Queue% Other% 


19:10 0.2 .1 88.9 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19311 0.2 8.3 91.7 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19;12 0.1 0.0 100.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19;13 0:2 7.1 92.9 029 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:14 D2 0.0 100.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:15 Cd 33 667 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:16 0.1 0.0 100.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:17 0.2 0.0 100.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:18 0.2 0.0 100.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:19 0.2 10.0 90.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:20 Q: 开 0.0 100.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 


4.3.4 SQL 语句 信息 


当 你 关注 某 个 特定 SQL 语 句 时 ， 可 以 通过 以 下 两 种 方式 显示 关于 该 SQL 语 句 的 详细 信息 : 在 显示 
排名 靠 前 的 SQL 语句 的 其 中 一 个 表 中 单 击 该 SQL 语句 的 SQL ID (例如 ， 图 4-17 和 图 4-21 ); 或 在 
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Performance 菜 单 中 通过 Search SQL 链接 进行 搜索 。 这 样 你 会 进入 相关 的 SQL Detail 页面。 注意 当 存在 
多 个 执行 计划 时 ， 可 以 在 SQL 语句 文本 和 标签 之 间 的 Plan Hash Value 下 拉 列 表 中 选择 其 中 一 个 。 除 了 
SQL 语句 ，SQL Detail 页 面 还 提供 如 下 标签 。 
口 Statistics 标 签 显示 执行 该 SQL 语句 的 平均 活动 会 话 数 ( 图 4-23 )、 执 行 统计 信息 ( 图 4-24 ) 以 及 
与 该 SQL 语句 关联 的 游标 的 相关 信息 .注意 执行 统计 信息 是 从 游标 在 库 缓存 中 初始 化 时 开始 计 
算 的 累计 值 。 该 信息 只 有 在 游标 还 没有 从 库 缓 存 中 超期 时 才 有 效 。 


Summary 

1 .) 4 

S 

局 3 

bd 

$2 

1 

如 

所 

9.08 415 7:20 7:25 
Feb 4, 2014 


图 4-23 ”Statistics 标 签 的 汇总 图 表 显 示 与 单个 SQL 语 句 相 关 的 平均 活动 会 话 


J 


Activity By Waits Activity By Time 
Elapsed Time (sec) 11,087.42 


CPU Time (sec) 577.25 
5 条 % Wait Time (sec) 10,510.17 
国 Remaining Waits(1.5%) Elapsed Time Breakdown 
国 User 1/O Waits(93.3%) SQL Time (sec) 11,087.42 
略 cpu(5.2%) PL/SQL Time (sec) 0.00 


Java Time (sec) 0.00 


Execution Statistics Other Statistics 
Total | Per Execution | Per Row |Execubons that Fetched al Rows (%) 100.00 
Average Persistent Mem (KB) 47,30 

4 


Executions 632,302 1 0.22 Average Runtime Mem (KB) 45.23 

Elapsed Time (sec) 11,087.42 0.02 <0.01 Serialzable Aborts 0 
Remote No 

CPU Time (sec) 577.25 <0.01 <0.01 Obsolete No 

Buffer Gets 17,171,539 27.16 6.00 Child Latch Number 0 

Disk Reads 1,855,323 2.93 0.65 

Direct Writes 0 0.00 0.00 

Rows 2,862,213 4.53 1 

Fetches 632,301 1.00 0.22 


图 4-24 Statistics 标 签 的 执行 统计 信息 显示 单个 SQL 语句 的 运行 时 行为 信息 
口 Activity 标 签 ( 图 4-25 ) 显示 CPU 使 用 率 和 等 竺 事件 占用 的 DB time。 这 里 显示 一 个 小 时 的 数据 。 
口 Plan 标签 显示 与 SQL 语句 相关 的 执行 计划 。 该 信息 只 有 在 执行 计划 还 没有 从 共享 池 里 超期 时 才 
会 显示 。 第 10 章 将 会 详细 介绍 如 何 阅读 执行 计划 和 判断 它 是 否 高 效 。 
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Maximum CPU __ 


Active Sessions 


男 db file parallel read 

闻 read by other session 
时 db file sequential read 
是 CPU Used 


07:11PM 07:16PM 07:21PM 07:26PM 
图 4-25 SQL 语句 级 别 的 活动 率 图 表 显 示 与 单个 SQL 语句 相关 的 CPU 使 用 率 和 等 待 事件 


口 Plan Control 标 签 显示 与 SQL 语句 相关 的 对 象 ， 如 SQL profile 和 SQL plan baseline。 这 些 对 象 会 
在 第 11 章 介绍 。 

口 Tuning History 标 签 显示 由 SQL Tuning advisor ( 详 见 第 11 章 ) 生成 的 信息 。 

口 SQL Monitoring 标 签 ， 只 从 11.1 版 本 起 才 有 ， 显 示 实 时 监控 的 相关 信息 。 如 果 这 部 分 信息 不 可 
用 ， 则 无 法 选中 该 标签 。 

如 果 使 用 的 是 11.2 及 以 后 的 版 本 , 并 且 拥 有 Tuning Pack 选 件 的 授权 , 那么 也 可 以 从 SQL Detail 页 面 
生成 一 份 SQL Details Active 报 告 。 由 于 报告 并 没有 比 SQL Detail 页 面 提供 更 多 的 信息 , 因此 只 有 在 想 要 
把 看 到 的 信息 保存 为 HTML 文 件 时 才 使 用 报告 。 这 样 可 以 在 以 后 查阅 或 发 给 其 他 大 = 如 有 和 需要， 不 用 
Enterprise Manager 也 能 生成 同样 的 报告 。 可 以 使 用 dbms_sqltune 包 下 的 report_sql_detai 国 数 。 该 师 
数 需 要 几 个 输入 参数 并 返回 一 个 包含 报告 的 CLOB。 有 些 输入 参数 可 以 用 来 改变 报告 要 显示 的 内 容 ， 
而 使 用 sql_id 参 数 可 以 指定 报告 要 显示 的 SQL 语句 。 以 下 查询 出 自 report_sql_detail.sql 脚 本 ， 演 示 
了 如 何 生成 一 份 报告 : 


SELECT dbms sqltune.report sql detail(sql id => 'c13sma6érkr27c') 
FROM dual 


如 果 不 使 用 Enterprise Manager 来 显示 执行 统计 信息 ( 图 4-24 ) 和 SQL 语 句 的 一 般 信息 ， 可 以 使 用 
如 下 脚本 中 的 一 个 : sqlarea.sql、sql.sql 和 sqlstats.sql。 顾 名 思 义 ,它们 分 别 从 v$sqlarea、v$sql 
和 v$sqlstats 中 提取 数据 。 更 多 信息 请 参考 4.4.4 节 。 


提示 sqlarea.sql、sql.sql 和 sqlstats.sql 提 供 了 一 个 Enterprise Manager 所 没有 的 特性 。 它 们 不 仅 
可 以 与 Enterprise Manager 一 样 ， 显 示 自 从 游标 加 载 后 的 累积 统计 信息 ， 还 会 记录 最 后 n 秒 的 统 
计 信 息 。 这 对 了 解 当 前 执行 的 统计 信息 很 有 用 。 实 际 上 ， 对 于 在 库 缓存 里 停留 很 长 时 间 的 游 
标 ， 由 累积 统计 信息 提供 的 信息 或 许 会 造成 误导 。 
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如 果 不 使 用 Enterprise Manager 显 示 单 独 SQL 语 句 的 活动 率 ， 可 以 使 用 ash_activity.sql 脚 本 ， 并 
指定 第 一 个 参数 为 al1 ( 这 代表 在 会 话 级 别 没有 限制 )， 第 二 个 参数 指定 为 SQL 语句 的 ID。 下 面 的 例子 
与 图 4-25 类 似 。 


SQL> @ash activity.sql all c1i3sma6rkr27c 


TIME AvgActSes CPU% UsrI0% SysI0% Conc% Appl% Commit% Config% Admin% Net% Queue% Other% 


19:10 2.6 B32 968 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19%11 2.4 5.5 94.5 0.0 0.0 0.0 0.0 0.0 0.0 00 0.0 0.0 
19:12 2:9 23 971:7 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:13 2.4 5.6 94.4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:14 2.4 4.2 95.8 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:15 2.1 6.3 93.7 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:16 Es8 7 9553 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:17 WL A 84 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:18 1.9 5.4 94.6 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:19 2 G8 2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:20 15 B99 开工 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:21 4.2 27 97 3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:22 12 8.2 9.8 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:23 0.8 10.2 89.8 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:24 1.0.15.3 84.7 0.0 0.0 0.6 0.0 0.0 0.0 0.0 0.0 0.0 
19:25 0.8 11.1 88.9 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:26 1.0 6.6 93.4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:27 0.9 9.3 90.7 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 
19:28 0.8 10.0 90.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 


4.4 不 使 用 Diagnostics Pack 进行 分 析 


不 使 用 Diagnostics Pack 选 件 来 分 析 性 能 问题 的 主要 操作 同上 一 节 介绍 的 基本 一 致 。 很 显然 ， 执 行 
分 析 时 不 使 用 Diagnostics Pack 选 件 授 权 的 动态 性 能 视图 。 这 里 有 两 个 要 求 : 第 一 ,不 能 使 用 Enterprise 
Manager; 第 二 ， 你 能 使 用 的 大 多 数 动态 性 能 视图 只 提供 累积 的 统计 信息 。 特 别 是 并 不 存在 活动 会 话 
历史 的 替代 品 。 结 果 就 是 你 无 法 查看 之 前 的 几 分 钟 发 生 了 什么 ， 也 无 法 查询 会 话 的 历史 操作 。 唯 一 没 
有 提供 累积 统计 信息 的 动态 视图 保存 着 度量 值 。 但 由 于 度量 值 主要 关注 比率 和 计数 ,这 对 分 析 性 能 问 
题 没什么 帮助 。 总 之 ,分 析 就 只 能 使 用 那些 提供 累积 统计 信息 的 动态 性 能 视图 了 。 

要 想 使 用 动态 性 能 视图 有 效 地 分 析 性 能 问题 , 需要 借助 工具 对 视图 提供 的 信息 进行 取样 。 这 样 的 
工具 可 以 是 简单 的 脚本 或 像 Enterprise Manager 一 样 复杂 的 工具 。 即 使 很 多 第 三 方 工具 提供 了 与 
Enterprise Manager 类 似 的 特性 ， 但 在 这 部 分 我 们 主要 关注 一 组 可 以 自由 使 用 的 脚本 ， 这 样 就 能 适用 于 
所 有 平台 。 由 于 大 部 分 脚本 都 处 理 累 积 统计 信息 ， 它 们 的 主要 目的 是 要 找 出 一 小 段 时 间 内 某 统计 值 的 
变化 率 。 因 此 脚本 会 反复 选择 同一 个 动态 性 能 视图 并 计算 每 次 选择 间 的 差 量 。 


4.4.1 数据 库 服 务 器 负载 


要 评估 数据 库 的 负载 ， 你 无 法 使 用 历史 度量 值 ( 需要 Diagnostics Pack 选 件 才 可 以 使 用 )。 应 该 查 
询 v$metric 视 图 来 获取 当前 度量 值 。 我 使 用 host_ load.sql 脚 本 来 获取 当前 值 。 该 脚本 有 一 个 参数 ， 用 
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来 指定 显示 数据 库 服 务 器 加 载 的 分 钟 数 。 下 面 是 一 段 脚 本 的 输出 ( 注意 ， 数 据 与 图 4-15 一 致 ); 


SQL> @host load.sql 16 


BEGIN TIME DURATION DB FG CPU DB BG CPU NON DB CPU OS LOAD NUM CPU 


14:05:00 60.10 1.71 0.03 0.03 4.09 8 
14:06:00 60.08 1 2 0.03 0.04 4.13 8 
14:07:00 59.10 1.89 0.03 0.04 4.96 8 
14:08:00 60.11 1.93 0.03 0.03 5.29 8 
14:09:00 60.09 1.73 0.03 0.59 4.60 8 
14:10:00 60.10 1.57 0.02 3.64 7.50 8 
14:11:00 60.16 4.15 0.02 6a60 14.82 8 
14:12:00 60.11 3421 0.02 6.60 到 好 8 
14:13:00 60.28 L197 0.02 6.62 15:30 8 
14:14:00 59.24 1.19 0.02 6.55 14.06 8 
14:15:00 60.09 1.59 0.04 0.18 9.19 8 
14:16:00 60.09 1.77 0.03 0.03 7.88 8 
14:17:00  .， 60.09 1.72 0.03 0.04 5.45 8 
14:18:00 60.11 1.87 0.03 0.03 5.28 8 
14:19:00 60.09 1.77 0.03 0.03 5.54 8 
14:20:00 60.08 1.72 0.03 0.04 4.83 8 


4.4.2 ”系统 级 别 分 析 


在 系统 级 别 上 进行 分 析 时 ， 首 先 需 要 检查 整个 系统 的 统计 信息 来 确认 数据 库 实例 的 负载 情况 。 可 
以 在 v$system wait_class 视 图 中 查询 到 这 些 统计 信息 。 更 确切 地 说 ， 应 该 使 用 脚本 (或 工具 ) 来 对 
v$system wait class 视 图 进行 取样 ， 以 获得 与 图 4-16 类 似 的 信息 ， 也 就 是 平均 活动 会 话 数 和 花费 在 每 
个 等 待 级 别 的 时 间 。 下 面 是 使 用 system activity_ sql 脚本 的 例子 ， 你 需要 指定 以 下 两 个 参数 . 

口 第 一 个 参数 指定 取样 时 间 间 隔 。 由 于 数据 库 引擎 不 会 实时 更 新 统计 信息 ， 将 取样 时 间 间 隔 指 

定 为 少 于 10~15 秒 通常 没有 意义 。 

口 第 二 个 参数 是 样本 的 数量 。 

下 面 的 例子 是 使 用 system_activity_sql 脚 本 生成 的 输出 ， 参 数 指定 了 20 个 间隔 为 15 秒 的 样本 ( 注 
意 数 据 与 图 4-16 显 示 的 内 容 一 致 )。 


SQL> @system activity.sql 15 20 


Time AvgActSess Other% Net% Adm% Conf% Comm% Appl% Conc% SysI0% UsrI0% Sched% CPU% 


19210:11 9.7 0-.0 0.0 .0.0 0.0 0.4 0.0 0.0 0.9 94.8 0.0 3.8 
19:10:26 10.0 0.0 0.0 0.0 0.0 0.5 ‘0.0 0.0 1.0 94.6 0.0 3.9 
19:10:41 10.0 0.0 0.0 0.0 0.0 0.4 0.0 0.0 1.0 94.8 0.0 3.8 
19:10:56 9.9 00 0.0 '0.0 0.0 0.4 0.0 0.0 1.0 94.6 0.0 4.0 
19511s 1 9.8 0.0 0.0 0.0 0.2 10 ,0.0 0.0 1:2 93x7 0.0 4.0 
19%11:26 9.5 0.0 0.0 0.0 0.0 0. OO.0 0.0 0.9 94.8 0.0 3.9 
19:11:41 9.6 0-0 0.0 0.0 0.0 0.4 0.0 0.0 0.9 94.8 0.0 3.8 
9: 机 :565 9.8 0.0 0.0 0.0 O00 0-5 ‘0.0 0.0 1.0 94.6 0.0 3.9 
19;12;11 9.7 0.0 0.0 0.0 0:0 0.3 ‘0.0 0.0 0.8 94.8 0.0 4.1 
19:12:26 9.5 0.0 0.0 0.0 0.0 0.4 0.0 0.0 1.0 94.5 0.0 4.0 
19:12:42 9.9 0.0 0.0 0.0 0.0 0.4 0.0 0.0 0.9 95;,1 0.0 了 .6 
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19:12:;57 9.8 0.0 0.0 0.0 0.9 0.4 0.0 0.1 0:9 _ 937>7 0.0 3:9 
.9513:12 9.4 0.0 0.0 0.0 0.0 0.4 0.0 0.0 1.0 94.7 0.0 4.0 
19313 :27 9.7 0.0 0.0 0.0 O00 QO 0.0 0.0 0.9 94.7 0.0 4.0 
19:13:42 9.8 0.0 0.0 0.0 0:0 0.4 -0.0 0.0 1.1 94.6 0.0 3:9 
19:13:57 140.1 0.0 0.0 0.0 0.0 0.4 0.0 0.0 1.0 94.9 0.0 3.7 
19:14:12 9.9 0.0 0.0 0.0 0.0 0.4 0.0 0.0 0.9 94.9 0.0 3.7 
19:14:27 9.6 0.0 0.0 0.0 QO0 O04 .0 0.0 1.0 94.5 0.0 4.0 
19:14:42 9.6 0.0 0.0 0.0 0.7 0.4 0.0 0.0 0.9 94.0 0.0 4.0 
19:14:57 9.8 0.0 0.0 0.0 0.0 0.4 0.0 0.0 0.8 94.8 0.0 4.0 


男 一 个 用 来 检查 全 系统 负载 情况 的 工具 是 时 间 模 型 统计 信息 ， 特 别 是 v$sys_time_model 视 图 里 的 
数据 。 它 可 以 告诉 你 哪个 引擎 处 理 数据 最 多 ， 万 一 处 理 数 据 最 多 的 是 SQL 引擎 ， 它 也 同样 会 告知 你 何 
种 操作 会 影响 性 能 ， 比 如 解析 。 同 样 在 这 里 ， 我 建议 你 使 用 脚本 (或 工具 ) 来 对 动态 性 能 视图 的 内 容 
取样 。 例 如 ， 在 一 段 时 间 内 ，time_model1.sql 脚 本 显示 了 一 段 时 间 内 所 有 时 间 模 型 统计 信息 的 详细 信 
息 。 要 使 用 它 必 须 指 定 以 下 两 个 参数 。 

口 第 一 个 参数 指定 取样 时 间 间 隔 。 由 于 数据 库 引擎 不 会 实时 更 新 统计 信息 ， 将 取样 时 间 间 隔 指 

定 为 少 于 10~15 秒 通常 没有 意义 。 

口 第 二 个 参数 是 样本 的 数量 。 

下 面 的 例子 是 使 用 time_model.sql 肢 本 生成 的 输出 ,参数 指定 了 2 个 间隔 为 15 秒 的 样本 ( 注意 脚本 
只 显示 取样 间隔 期 间 统计 值 的 变化 ) 。 


SOL> @time model.sql 15 2 


Time Statistic AvgActSess Activity% 
19:14:49 DB time 9.8 98.6 
.DB CPU 0.3 3.4 
.Sql execute elapsed time 9.7 97.3 
.PL/SQL execution elapsed time (0 针 没 
background elapsed time 0.1 1.4 
.background cpu time 0.0 0.4 
Time Statistic AvgActSess Activity% 
19:15:04 DB time 9.8 98.8 
.DB CPU 0.3 3 
.Sql execute elapsed time 9.7 97.8 
.parse time elapsed 0.0 Os3 
.hard parse elapsed time 0.0 0.3 
.PL/SQL execution elapsed time Qa ee 
background elapsed time 0.1 LE 
.background cpu time 0.0 0.3 


你 同样 可 以 使 用 时 间 模 块 统 计 信 息 来 确认 观察 到 的 大 部 分 活动 是 否 由 某 些 会 话 产 生 。 为 此 ,你 需 
要 v$sess_time_model 视 图 提供 的 会 话 级 别 统计 信息 。 同 样 ， 应 该 使 用 脚本 ( 或 工具 ) 来 对 动态 性 能 视 
图 的 内 容 取样 。 我 将 基于 active_sessions.sql 脚 本 举例 。 脚 本 的 目的 是 显示 在 给 定 的 时 间 段 里 ，top 
session 花 费 了 多少 DB time。 要 使 用 此 脚本 ， 需 要 指定 以 下 三 个 参数 。 
口 第 一 个 参数 指定 取样 时 间 间 隔 。 由 于 数据 库 引擎 不 会 实时 更 新 统计 信息 ， 将 取样 时 间 间 隔 指 
定 为 少 于 10~15 秒 通常 没有 意义 。 
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口 第 二 个 参数 是 样本 的 数量 。 

口 第 三 个 参数 指定 输出 的 会 话 数 。 通 常 指定 少 于 10~20 个 会 话 是 无 意义 的 。 

下 面 的 例子 是 使 用 active_sessions.sql 脚 本 生成 的 输出 ， 参 数 指定 了 取样 间隔 为 15 秒 ,收集 10 个 
会 话 的 信息 ( 注意 ， 数 据 与 图 4-18 显 示 的 内 容 一 致 )。 


SQL> @active sessions.sSql 15 1 10 


Time #Sessions #Logins SessionId Username Program Activity% 
19:14:49 117 0 195 SOE JDBC Thin Client 1.8 
224 SOE JDBC Thin Client 3 
225 SOE JDBC Thin Client 1.5 
232 SOE JDBC Thin Client 1.5 
7 SOE JDBC Thin Client 1.5 
227 SOE JDBC Thin Client 1.4 
74 SOE JDBC Thin Client 1.4 
16 SOE JDBC Thin Client 1.4 
474 SOE JDBC Thin Client 1.4 
68 SOE JDBC Thin Client 1.4 


Top-10 Total 
注意 ,之 前 的 输出 也 显示 了 每 个 间隔 打开 的 会 话 和 登录 数 。 这 个 信息 很 重要 ， 因 为 脚本 无 法 发 现 
在 取样 间隔 期 间 终 止 的 会 话 执行 了 哪些 动作 。 所 以 ， 当 你 发 现 会 话 数 在 减少 ， 或 者 登录 数 很 高 但 会 话 
数 却 没有 按 比 例 增加 时 ， 就 应 该 提高 警惕 了 。 
根据 脚本 输出 ， 如 果 大 部 分 的 活动 率 是 由 几 个 会 话 造成 的 ( 比如 ， 单 个 会 话 的 活动 率 至 少 是 两 位 
数 百 分 比 )， 你 就 应 该 定位 会 话 以 对 其 进行 进一步 的 分 析 。 根 据 上 面 的 例子 ， 如 果 没 有 突出 的 会 话 ， 
就 表明 会 话 活动 率 很 平均 。 因 此 , 或 许 应 该 根据 会 话 ID 以 外 的 维度 对 性 能 统计 数据 进行 聚合 。 建 议 你 
使 用 Tanel P6der 开 发 的 脚本 来 实现 。 脚 本 名 叫 Snapper"( snapper.sql ), 它 的 主要 功能 是 以 跟 采 样 周期 
成 反比 的 频率 对 v$session 视 图 进行 取样 。 取 样 期 间 Snapper 会 检查 指定 会 话 的 状态 ,而 对 于 活动 会 话 ， 
会 收集 它们 活动 率 的 信息 ( 比如 在 执行 的 SQL 语句 )。 由 于 Snapper 是 一 个 非常 灵活 且 强 大 的 脚本 ， 可 
以 使 用 很 多 参数 ， 因 此 这 里 无 法 进行 完整 的 介绍 。 这 里 只 介绍 一 些 基础 知识 并 展示 几 个 例子 。 有 关 更 
多 信息 ， 请 阅读 脚本 的 标 头 。 
Snapper 需 要 四 个 参数 。 
口 第 一 个 参数 指定 需要 取样 的 动态 性 能 视图 。 如 果 指 定常 量 ash， 则 会 对 v$session 进 行 取样 。 这 
样 做 的 目的 是 收集 与 活动 会 话 历 史 相 似 的 数据 。 指 定 这 个 参数 后 ， 也 可 以 指定 v$session 视 图 
的 相关 列 来 进行 聚合 。 例 如 ，ash=username+sql id 表 示 数 据 会 根据 v$session 视 图 的 username 
和 sql_id 列 进行 聚合 ( 视图 中 的 任何 列 都 可 以 指定 )。 当 指定 常量 stats 时 ， 会 对 v$sesstat 、 
v$sess time model 和 v$session_event 进 行 取 样 。 
口 第 二 个 参数 指定 取样 周期 ， 单 位 为 秒 。 
口 第 三 个 参数 指定 样本 数量 。 
口 第 四 个 参数 指定 取样 的 会 话 。 这 里 可 以 指定 单独 会 话 ID 、 多 个 会 话 ID 列表 ( 用 逗号 分 隔 )， 指 
定常 量 al1 对 所 有 会 话 进行 取样 , 也 可 以 指定 查询 返回 的 会 话 ID , 或 可 用 表达 式 的 其 中 一 个 ( 例 


> 
上 人 
‘Oo 


D 可 以 在 http://blog.tanelpoder.com/files/scripts.snapper.sql 下 载 到 该 脚本 ， 
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如 ，user=chris 表 示 查 询 由 指定 用 户 打 开 的 所 有 会 话 。 要 获取 可 用 表达 式 的 完整 列表 ,请 参阅 
脚本 的 标 头 )。 

第 一 个 使 用 Snapper 的 例子 显示 如 何 收集 与 图 4-17 相 似 的 信息 。 四 个 参数 如 下 。 

口 第 一 个 参数 ( ash=sql id ) 指定 查询 v$session 视 图 ， 并 根据 SQL _ID 聚 合 结果 数据 。 

口 第 二 个 参数 (15 ) 指定 使 用 15 秒 取样 间隔 。 

口 第 三 个 参数 ( 1 ) 指定 一 个 样本 。 

口 第 四 个 参数 ( all ) 指定 对 所 有 会 话 进行 取样 。 

SQL> @snapper.sql ash=sql id 15 1 all 


196% | c1i3smabrkr27c 

186% | 8dqOvimjngj7t 

122% | bymb3ujkr3ubk 

107% | 7hk2m2702ua0g 

82% | Oyaso1iu2p9ch4 

63% | 8z3542ffmp562 

62% | Obzhqhhj9mpaa 

30% | 5mddt5kt45r83 
26% | 

26% | f9u2k84v884y7 


请 注意 ， 在 上 面 的 例子 中 ，Active% 列 或 许 会 大 于 100%。 这 在 对 多 个 会 话 进行 取样 时 会 发 生 。 例 
如 上 面 的 输出 ， 在 取样 期 间 ，top SQL 语句 ( c13sma6rkr27c ) 平均 被 1.96 个 会 话 执行 。 

第 二 个 例子 显示 如 何 收集 与 图 4-19 相 似 的 信息 。 对 比 上 一 个 例子 ， 只 有 第 一 个 参数 需要 修改 。 它 
需要 根据 会 话 属性 module 和 action 聚 合 数据 ( ash=module+action )。 


SQL> @snapper.sql ash=module+action 15 1 all 


97% | New Order getProductDetailsByCatego 
94% | New Order 
86% | Process Orders 


| 

| 
58% | Browse Products | getCustomerDetails 
32% | New Order | getCustomerDetails 
28% | New Customer | 
22% | New Order | getProductQuantity 
9% | | 
8% | Browse and Update Orders | getCustomerDetails 
3% | Browse Products | getProductDetails 


4.4.3 会 话 级 别 分 析 


前 面 使 用 Snapper 的 例子 展示 了 如 何 分 析 整 个 系统 的 活动 率 ( 换 名 话说， 所 有 会 话 的 活动 率 )。 然 
而 Snapper 同 样 可 以 只 针对 某 个 会 话 。 对 此 ， 第 四 个 参数 就 要 由 al1 改 成 具体 的 某 个 会 话 的 ID。 下 面 的 
两 个 例子 分 别 展示 了 如 何 获 得 与 图 4-20 和 图 4-21 类 似 的 信息 。 
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SQL> @snapper.sql ash=event 15 1 172 


22% | db file sequential read 


1% | ON CPU 


1% | db file parallel read 


SQL> @snapper.sql ash=sql id+module+taction 15 1 172 


和 


7% | c1i3sma6rkr27c 
3% | 8dqovlmjngj7t 
3% | 0yas01u2p9ch4 
1% | 7hk2m2702Ua0g 


1% | 8dqovimjngj7t 
1% | 8dqovimjngj7t 
1% | bymb3ujkr3ubk 
1% | 8z3542ffmp562 
1% | 0bzhqhhj9mpaa 


4.4.4 ”SQL 语句 信息 


| New Order 

| New Order 

| New Order 

| Process Orders 
| Browse Products 

| Browse and Update Orders 
| New Order 

| New Order 

| New Customer 


getProductDetailsByCatego 
getCustomerDetails 


getCustomerDetails 
getCustomerDetails 


getProductQuantity 


定位 了 大 活动 率 的 SQL 语句 之 后 , 可 以 使 用 以 下 脚本 中 的 一 个 来 显示 信息 : sqlarea.sql、 sql.sql 
和 sqlstats.sq1。 顾 名 思 义 ， 它 们 分 别 从 v$sqlarea、v$sq1 和 v$sqlstats 中 提取 数据 。 这 三 个 脚本 需要 


两 个 输入 参数 。 


口 第 一 个 参数 指定 SQL 语句 的 ID。 

口 第 二 个 参数 指定 脚本 显示 的 是 从 游标 加 载 进 库 缓存 后 的 累积 统计 值 还 是 当前 增加 的 统计 值 。 
将 该 参数 设置 成 大 于 0 的 数字 时 ， 将 启用 后 一 种 模式 。 那 样 的 话 ， 会 根据 参数 ( 秒 数 ) 指定 的 
间隔 时 间 ， 查 询 两 次 统计 值 。 当 指定 其 他 值 时 ， 将 显示 前 者 。 

下 例 展示 了 如 何 使 用 sqlstats.sql 脚 本 显示 ID 为 c13sma6rkr27c 的 SQL 语句 最 后 15 秒 的 统计 信息 : 

SQL> @sqlstats.sql ci3sma6rkr27c 15 


SQL Id 


Cc13Sma6TKkTr27< 
1640444070 


Total Parses 
Loads / Hard Parses 
Invalidations 


Cursor Size / Shared (bytes) 


Activity by Time 


Elapsed Time (Seconds ) 33.559 
CPU Time (seconds ) 0.568 
Wait Time (seconds) 32.991 


Application Waits (%) 0.000 
Concurrency Waits (%) 0.000 
Cluster Waits (%) 0.000 
User I/0 Waits (%) 97.994 
Remaining Waits (%) 0.313 
CPU (%) 1.692 
Elapsed Time Breakdown 

SQL Time (seconds) 33.559 
PL/SQL Time (seconds) 0.000 
Java Time (seconds) 0.000 
Execution Statistics Total Per Execution Per Row 
ER PT re je ee er ee ep iii 
Elapsed Time (milliseconds) 33,559 23 5.133 
CPU Time (milliseconds) 568 0 0.087 
Executions 1,436 和 0.220 
Buffer Gets 43,305 30 6.624 
Disk Reads 4,292 如 0.656 
Direct Writes 0 0 0.000 
Rows 6,538 5 1.000 
Fetches 1,440 下 0.220 
Average Fetch Size 5 

Other Statistics 

Executions that Fetched All Rows (%) 100 
Serializable Aborts 0 


4.5 ”小结 


本 章 介绍 了 一 个 发 生性 能 问题 时 用 于 定位 性 能 问题 的 分 析 路 线 图 , 同时 还 介绍 了 几 种 可 以 使 用 的 
工具 和 技术 。 尽 管 提供 的 分 析 路 线 图 很 有 帮助 ,但 它 也 只 是 冰山 一 角 。 总 之 ,找到 一 种 妥善 的 处 理 方 
法 来 快速 成 功 地 定位 问题 才 是 最 重要 的 。 对 此 ， 我 已 经 强调 过 很 多 次 了 。 

本 章 介绍 了 发 生性 能 问题 时 该 如 何 分 析 。 但 如 果 问 题 发 生 在 过 去 呢 ? 你 能 找 出 发 生 了 什么 ,并 且 
防止 其 再 次 发 生 吗 ? 第 5 章 将 介绍 如 何 使 用 包含 历史 性 能 统计 信息 的 知识 库 为 这 些 问题 找到 答案 。 


不 可 重 现 问题 的 事后 


本 章 将 介绍 如 何 分 析 一 个 无 法 重 现 或 监控 到 的 性 能 问题 。 换 句 话 说 ， 当 问题 发 生 过 后 ,无 法 使 用 
SQL 跟踪 ， 也 无 法 查看 动态 性 能 视图 ， 这 种 情况 下 该 如 何 分 析 问 题 。 在 这 种 情况 下 ， 能 够 在 你 想 要 分 
析 的 时 间 段 做 出 可 靠 分 析 的 唯一 方法 就 是 使 用 包含 性 能 统计 信息 的 知识 库 。 


5.1 知识 库 


Oracle 数 据 库 提供 了 两 个 知识 库 ， 其 中 存储 的 信息 可 以 用 于 分 析 过 去 发 生 过 的 性 能 问题 : 
口 Automatic Workload Repository ( AWR ) 
口 Statspack 
由 于 AWR 是 Statspack 的 进化 版 ， 因 此 它 也 基于 以 下 三 个 同样 的 基本 概念 ( 这 些 概念 就 是 随 其 提供 
的 实用 程序 )。 
口 在 固定 的 间隔 里 ( 例如 30 分 钟 )， 许 多 动态 性 能 视图 的 内 容 被 导入 一 组 表 中 。 产 生 的 结果 数据 
被 称 为 快照 (snapshot )， 快 照 通过 快照 ID 来 进行 识别 。 有 些 动 态 性 能 视图 会 导出 所 有 数据 ， 
有 些 则 只 会 导出 一 部 分 数据 。 例 如 ，SQL 语 句 的 信息 只 会 导出 消耗 最 大 的 。 
口 针对 AWR， 可 以 通过 Oracle 提 供 的 脚本 或 者 工具 ( 例如 ，Enterprise Manager 或 SQL Developer ) 
找 出 在 两 个 快照 限定 的 时 间 段 内 ， 知 识 库 中 统计 信息 的 变化 情况 。 
口 通常 情况 下 ， 快 照 不 会 无 限期 地 保存 下 去 ， 经 过 一 段 时 间 后 就 会 被 删除 。 指 定时 间 段 的 快 
照 可 以 标记 成 基线 (baseline )， 这 样 就 不 会 被 删除 。 基 线 可 以 用 来 做 对 比 。 例 如 ， 如 果 你 
在 系统 运行 良好 的 时 候 保 存 了 一 段 时 间 的 基线 ， 就 可 以 在 性 能 问题 发 生 时 与 基线 的 时 间 段 
做 对 比 。 
注意 ,选取 快照 的 间隔 长 度 是 非常 重要 的 。 实 际 上 ， 通 常 更 短 的 间隔 要 比 一 小 时 甚至 更 长 的 间隔 
有 用 。 这 主要 有 两 个 原因 。 首 先 ， 对 一 个 很 长 的 时 间 段 计算 比率 或 平均 值 会 造成 很 大 的 误导 。 其 次 ， 
鉴于 一 些 动态 性 能 视图 提供 的 信息 变化 非常 快 ， 在 获取 快照 的 时 候 ， 有 用 的 信息 或 许 已 经 不 在 了 。 例 
如 ,一 条 消耗 了 大 量 资源 的 SQL 语 句 ， 可 能 会 在 快照 捕获 前 从 库 缓存 中 移 除 ， 从 而 导致 快照 没有 记录 
到 它 。 因 此 ， 我 通常 建议 时 间 间 隔 为 20 或 30 分 钟 。 
表 5-1 总 结 了 AWR 与 Statspack 之 间 的 主要 区 别 。 鉴 于 AWR 要 比 Statspack 强 大 的 多 ， 在 有 许可 的 情 
况 下 你 更 应 该 使 用 AWR。 
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表 5-1 AWR 与 Statspack 之 间 的 主要 区 别 


Automatic Workload Repository Statspack 
与 数据 库 紧密 整合 ， 并 且 自 动 安 装 和 管理 需要 DBA 手 动 安装 和 管理 
基于 ASH 保 存 系统 级 别 、SQL 语 句 级 别 以 及 会 话 级 别 的 信息 ”只 保存 系统 和 SQL 语句 级 别 的 信息 
Enterprise manager 可 以 管理 其 内 容 Enterprise Manager 没 有 集成 
自动 诊断 性 能 问题 会 参考 Ni 不 会 参考 其 内 容 
需要 Oracle 诊 断 包 组 件 和 企 所 有 版 本 都 可 使 用 
不 能 在 只 读 模 式 的 备 wa 上 使 用 11.1 之 后 的 版 本 可 以 在 只 读 模 式 的 备用 数据 库 上 使 用 


5.2 自动 工作 负载 存储 库 


本 节 将 介绍 如 何 配置 AWR， 捕 获 快照 并 管理 基线 。 稍 后 的 5.4 节 将 会 介绍 如 何 利用 存储 在 AWR 中 WH 
的 信息 。 此 时 重要 的 是 要 知道 AWR 中 存储 的 信息 是 通过 dba_hist 前 级 的 数据 字典 视图 ( 在 12.1 多 租户 
环境 下 ， 也 存在 cdb_hist 前 缀 的 视图 ) 公开 的 。 


5.2.1 执行 配置 


AWR 会 在 每 个 数据 库 上 自动 安装 并 配置 。 因 化 从 它 存在 之 初 , 数据 库 引擎 就 会 捕获 记录 工作 负荷 
的 快照 。 


警告 ”当初 始 化 参数 statistics level 设置 成 basic 时 ， 数 据 库 引擎 不 会 自动 捕获 快照 。 


配置 基于 以 下 三 个 参数 

口 Snapshot interval: 两 个 快照 之 间 的 时 间 间 隔 〈 单 位 : 分 钟 )。 最 小 值 和 最 大 值 分 别 是 10 分 钟 和 
100 年 。 默 认 是 1 小 时 

口 Retention period: 快照 的 保存 时 间 (单位 : 分 钟 )。 最 小 值 和 最 大 值 分 别 是 1 天 和 100 年 。 如 果 
指定 0， 那 么 快照 会 永久 保存 。 在 10.2 版 本 中 默认 值 是 7 天 ，11.1 版 本 之 后 默认 值 是 8 天 

口 Top SQL statements: 每 个 快照 都 会 记录 消耗 最 大 的 SQL 语句 数量 。 览 于 每 个 快照 会 记录 多 个 
消耗 种 类 ( 例如 ，top elapsed time 、top CPU utilization 和 top parse calls )， 因 此 每 个 快照 实际 保 
存 的 SQL 语句 数量 要 上 比 参 数 指定 的 值 高 。 该 参数 的 默认 值 ( DEFAULT ) 是 30, 最 大 值 ( MAXIMUM ) 
是 50 000。 这 里 DEFAULT 可 以 是 30 或 100， 这 要 根据 捕获 快照 的 fush level 来 定 ( 参见 5.2.2 节 )， 


为 了 保证 指定 的 SQL 语句 信息 在 每 个 快照 里 都 捕获 到 ( 无 论 它 是 否 为 消耗 最 大 的 SQL )， 从 11.1 
版 本 之 后 ， 可 以 将 语句 的 SQL ID 标记 为 colored。 可 以 使 用 dbms workload repository 包 下 的 
add_colored sql 和 remove_colored sql] 过程 分 别 标记 或 者 取消 标记 SQL ID 的 colored。 请 注意 两 个 过 
程 都 需要 指定 操作 的 SQL ID 
要 知道 哪些 SQL 语 句 被 标记 为 colored, 可 以 查询 dba hist colored sql 视 图 , 在 12.1 多 租户 环境 
下 ， 可 以 查询 cdb_hist colored sql 视 图 
a CECEEEEPCTEREEEEEIEEPrPRE 二 POP 天- 下 汪 下 2 二 王 下 臣 -En 
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下 面 的 查询 展示 了 如 何 显示 参数 的 当前 值 ( 注意 从 11.1 版 本 之 后 这 些 值 是 默认 值 ): 


SQL> SELECT snap interval, retention, topnsql 
2 FROM dba hist wr control; 


SNAP_INTERVAL RETENTION TOPNSQL 


+00000 01;00:00.0 +00008 00:00:00.0 DEFAULT 


可 以 使 用 dbms_workload repository 包 下 的 modify_snapshot settings 过 程 来 修改 默认 配置 ,例如 ， 
以 下 调用 设置 间隔 时 间 为 20 分 钟 ， 保 存 35 天 : 


dbms_workload repository.modify snapshot settings( 
interval => 20, 
retention => 35*60*24, 
topnsql => "DEFAULT 
); 
AWR 的 数据 会 保存 在 sysaux 表 空间 中 。 存储 空间 的 大 小 完全 取决 于 这 三 个 参数 如 何 设置 。 通 常情 
况 下 ， 每 个 快照 会 至 少 占用 1 兆 空 间 。 如 果 你 想 知道 当前 使 用 了 多 少 空间 ， 可 以 执行 以 下 查询 : 
SELECT space usage kbytes 


FROM v$sysaux occupants 
WHERE occupant name = “SM/ANR 


5.2.2 ”捕获 快照 


快照 除了 可 以 由 数据 库 引擎 自动 捕获 外 ,也 可 以 手工 捕获 。 想 要 保存 特定 时 间 段 的 信息 时 ， 快 照 
会 很 有 帮助 。 要 捕获 快照 ， 需 要 调用 dbms _workload xepository 包 下 的 create_snapshot 子 程序 。 这 个 
包 下 有 两 个 子 程序 : 一 个 函数 和 一 个 存储 过 程 。 它 们 都 需要 一 个 参数 用 来 指定 flush level ( TYPICAL 或 
ALL， 前 者 是 默认 值 )。 如 果 使 用 TYPICAL， 会 保存 每 个 分 类 的 前 30 个 top SQL 语句 。 如 果 指 定 ALL， 会 
存 前 100 个 。 函 数 和 存储 过 程 唯一 的 不 同 是 函数 会 返回 快照 IDs 以 下 查询 显示 指定 flush level 为 ALL 的 情 
况 下 如 何 捕获 快照 并 显示 关联 的 快照 ID: 


SOL> SELECT dbms workload repository.create snapshot(flush level => 'ALL') AS snap_id 
2 FROM dual; 


SNAP_ID 


保存 在 AWR 中 的 快照 可 以 通过 dba_hist_snapshot 视 图 查看 ， 在 12.1 多 租户 环境 下 ， 可 以 查看 
cdb_hist_snapshot 视 图 : 
SQL> SELECT begin interval time, end interval time, 
2 decode(snap level, 1, 'TYPICAL', 2, 'ALL', snap level) AS snap level 


3 FROM dba hist snapshot 
4 WHERE snap id = 738; 


BEGIN INTERVAL TIME END_INTERVAL TIME SNAP_ LEVEL 


22-APR-14 04.00.22.234 PM 22-APR-14 04.06.58.230 PM ALL 
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5.2.3 ”管理 基线 


基线 是 由 多 个 连续 的 快照 组 成 的 。 基 线 有 两 种 。 
口 固定 基线 ( fixed baseline): 由 静态 的 开始 快照 ID 和 静态 的 结束 快照 ID 限定 的 一 组 连续 快照 。 
可 以 根据 需要 创建 多 个 基线 。 


口 移动 窗口 基线 (moving window baseline ): 指定 时 间 内 ( 特别 是 以 天 为 单位 ) 的 一 组 连续 快照 
并 且 以 最 近 的 快照 作为 结束 。 每 个 数据 库 都 有 一 个 移动 窗口 基线 作为 数据 引擎 的 自 适 应 阔 值 
( 更 多 信息 请 参考 Performance Tuning Guide 手 册 )。 这 种 基线 是 从 11.1 版 本 之 后 才 有 的 。 


1. 管理 固定 基线 

dbms workload repository 包 提供 了 多 个 命名 为 create_baseline 的 函数 和 存储 过 程 用 来 创建 基 
线 。 虽 然 它 们 在 两 个 方面 有 所 区 别 ， 但 都 实现 同样 的 基本 功能 。 首 先 ， 基 线 的 起 始 和 结束 可 以 指定 
两 个 ID 或 两 个 时 间 (后 者 只 有 在 11.1 版 本 之 后 才 可 用 )。 其 次 ， 函 数 会 返回 新 创建 的 基线 ID。 注 意 所 
有 的 子 程序 都 需要 参数 指定 基线 的 名 称 ， 同 时 也 可 使 用 可 选 参 数 指定 基线 在 多 少 天 后 自动 删除 ( 默 
认 值 为 NULL， 指 定 没有 过 期 的 基线 )。 例 如 ， 以 下 调用 展示 了 如 何 创 建 名 为 TEST 的 基线 并 指定 基线 于 
30 天 后 过 期 : 

dbms_workload repository.create baseline( 地 
start snap_id => 738, 
end snap id => 739, 
baseline name => 'TEST', 
expiration =》30 


) 
保存 在 AWR 中 的 快照 可 以 通过 dba_hist baseline 视 图 查看 ， 在 12.1 多 租户 环境 下 ， 可 以 通过 
cdb hist_baseline 视 图 查看 : 
SQL> SELECT start snap id, start snap time, end snap_id，end_snap_time 
2 FROM dba hist baseline 


3 WHERE baseline name = “TEST 
4 AND baseline type = 'STATIC'; 


START_SNAP_ID START SNAP TIME END SNAP_ID END SNAP_ TIME EXPIRATION 


738 22-APR-14 04.06.58.230 PM 739 22-APR-14 04.12.50.933 PM 30 


dbms_workload repository 包 提供 了 select_baseline_metric 函 数 用 来 显示 基线 ( 同样 也 对 移动 窗 
口 基线 适用 ) 相关 的 度量 值 。 以 下 查询 展示 了 如 何 显示 TEST 基线 相关 的 度量 值 : 
SOL> SELECT metric name, metric unit, minimum, average, maximum 


2 FROM table(dbms workload repository.select baseline metric('TEST')) 
3 ORDER BY metric name; 


METRIC NAME METRIC UNIT MINIMUM AVERAGE MAXIMUM 
Active Parallel Sessions Sessions 0 0 0 
Active Serial Sessions Sessions 0 1.42857143 六 


Average Active Sessions Active Sessions 0 .413742101 3.49426268 
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User Transaction Per Sec Transactions Per Second 0 6.98898086 49.2425504 


VM jin bytes Per Sec bytes per sec 0 0 0 
VM out bytes Per Sec bytes per sec 0 0 0 


dbms workload repository 包 提供 了 rename_baseline 过 程 来 对 基线 重合 名。 该 过 程 需要 参数 指定 
旧 命 名 与 新 命名 。 例 如 ， 以 下 调用 显示 如 何 将 TEST 基 线 改 名 为 TEST1: 


dbms_workload repository.rename baseline( 
old baseline name => 'TEST ， 
new baseline name => 'TEST1' 
); 
最 后 ， 可 以 使 用 dbms_workload_repository 包 下 的 drop_baseline 过 程 来 删除 基线 。 该 过 程 需要 指 
定 参 数 基线 名 ， 以 及 指定 是 否 删除 与 基线 相关 的 快照 ( 默认 情况 下 不 删除 ) 的 可 选 参数 。 例 如 ， 以 下 
调用 展示 了 如 何 删除 TEST1 基 线 及 其 相关 的 快照 : 


dbms workload repository.drop baseline( 
baseline name => "TEST1 ， 
cascade => TRUE 


烛 


2. 管理 移动 窗口 基线 

移动 窗口 基线 没有 太 多 需要 管理 的 内 容 。 实 际 上 ,我们 仅 可 以 调用 dbms_workload Tepository 包 
下 的 modify baseline window_size 过 程 来 修改 窗口 大 小 。 参 数 需要 指定 新 窗口 大 小 的 天 数 。 比 如 ， 以 
下 调用 展示 了 如 何 将 窗口 大 小 设置 为 30 天 : 

dbms_workload repository.modify baseline window size(window size => 30); 

调用 modify_baseline_window_size 过 程 唯一 需要 满足 的 要 求 是 ， 新 的 窗口 大 小 不 能 大 于 使 用 快照 
的 保存 期 。 如 果 没 有 满足 要 求 , 数据 库 引 擎 会 抛 出 如 下 异常 :ORA-13541: systemmoving window baseline 
size greater than retention。 


可 以 使 用 以 下 查询 来 显示 当前 窗口 大 小 ( 注意 ， 从 11.1 版 本 开始 这 些 值 为 默认 值 ): 


SQL> SELECT baseline name, moving window size 
2 FROM dba hist baseline 
3 WHERE baseline type = 'MOVING WINDOW'; 


BASELINE NAME MOVING WINDOW_SIZE 


SYSTEM MOVING WINDOW 8 


5.3 Statspack 


本 节 介 绍 如 何 安装 和 配置 Statspack、 捕 获 快照 和 管理 基线 。 稍 后 在 5.5 节 中 将 介绍 如 何 利用 存储 在 
Statspack 知 识 库 中 的 信息 。 
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提示 “Oracle 数据 库 手册 不 再 提供 关于 Statspack 的 信息 。 可 以 在 $ORACLE_HOME/rdbms/admin 目 录 
下 的 spdoc.txt 文 件 中 找到 安装 、 配 置 、 管 理 和 使 用 Statspack ( 以 及 其 他 安装 脚本 和 工具 ) 的 
详细 信息 。Oracle Support 文 档 Jnstalling and Using Standby Statspack in 11g (454848.1 ) 提供 了 
关于 在 只 读 模 式 的 备用 数据 库 上 使 用 Statspack 的 信息 。 


5.3.1 执行 安装 


为 了 安装 Statspack， 需 要 以 sys 用 户 身 份 连接 数据 库 ， 并 运行 $ORACLE_HOME/rdbms/admin 目 录 下 的 
spcreate.sql 肢 本, 该 脚本 会 创建 perfstat 用 户 以 及 用 户 下 大 部 分 需要 运行 Statspack 的 对 象 。 此外, 它 
还 会 创建 多 个 public 同 义 词 和 sys 模 式 下 的 视图 。 执 行 期 间 ， 脚 本 会 询问 perfstat 用 户 的 密码 ， 使 用 的 
临时 表 空 间 和 存放 表 和 索引 的 表 空 间 。 注 意 ， 在 执行 脚本 前 ， 要 指定 的 临时 表 空 间 和 表 空 间 就 需要 创 
建 好 。 如 果 不 希 望 创 建新 的 表 空间 ， 可 以 选择 默认 的 临时 表 空 间 和 sysaux 表 空间 。 


5.3.2 配置 存储 库 


Statspack 的 配置 基于 三 类 参数 ， 保 存在 perfstat 模 式 的 stas$statspack_parameter 表 下 。 
口 快照 级 别 ( Snapshot level ): 定义 捕获 快照 时 存储 的 数据 。 表 5-2 简 单 介绍 了 可 用 的 快照 级 别 。 
同样 ， 在 stats$level description 表 里 也 包含 对 每 个 级 别 的 简介 。 


表 5-2 ”Statspack 快 照 级 别 
级 别 描 述 
捕获 一 般 性 能 统计 信息 
捕获 一 般 性 能 统计 信息 〈 同 级 别 0) ， 也 包括 超过 效 值 的 SQL 语句 统计 信息 。 这 是 默认 级 别 
除了 低级 别 收集 的 所 有 统计 信息 外 ， 还 包括 执行 计划 (包括 使 用 统计 信息 ) 
除了 低级 别 收集 的 所 有 统计 信息 外 ， 还 包括 超过 国 值 的 段 级 别 统计 信息 (比如 ， 逻辑 读 和 物理 
读 的 数量 ) 
10 除了 低级 别 收集 的 所 有 统计 信息 外 ， 还 包括 门 的 统计 信息 


口 SQL 语 和 句 阅 值 (SQL statement threshold ): 有 六 个 阅 值 ( 执行 数 、 解 析 调用 数 、 物 理 读 数 、 逮 
辑 读 数 、 可 共享 内 存 数 和 子 游标 数 ) 用 来 判断 是 否 捕获 SQL 语句 。 只 有 至 少 超 过 其 中 一 个 冰 值 
时 才 会 捕获 SQL 语句 。 

口 段 统计 信息 阅 值 ( Segment statistics threshold ): 有 七 个 靖 值 ( 逻辑 读数 、 物 理 读数 、buffer busy 
wait 数 、row lock wait 数 、ITL wait 数 、 全 局 缓存 一 致 性 读 块 数 和 全 局 缓存 当前 块 数 ) 用 来 判断 
是 否 捕获 段 信 息 。 只 有 至 少 超过 其 中 一 个 国 值 时 才 会 捕获 段 信息 。 

以 下 查询 展示 了 每 个 参数 的 实际 值 ( 这 里 显示 的 是 安装 过 后 的 默认 值 ): 

SQL> SELECT parameter, value 
2 FROM stats$statspack parameter 


3 UNPIVOT ( 
4 value FOR 
5 
6 


~ a uh So 


parameter IN (snap_ level, executions th, parse calls th, disk reads th, buffer gets th, 
sharable mem th, version count th, seg phy reads th, seg log reads th, 
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7 seg buff busy th, seg rowlock w th, seg it] waits th, seg cr bks rc th， 
8 seg cu bks rc th) 
9 ); 

PARAMETER VALUE 

SNAP_LEVEL 5 

EXECUTIONS_TH 100 

PARSE_CALLS TH 1000 

DISK READS TH 1000 


BUFFER_GETS TH 40000 
SHARABLE MEM TH 1048576 
VERSION_COUNT_TH 20 
SEG PHY READS TH 1000 
SEG LOG READS TH 10000 
SEG BUFF BUSY TH 100 
SEG ROWLOCK W TH 100 
SEG ITL WAITS TH 100 
SEG CR BKS RC TH 1000 
SEG CU BKS RC TH 1000 


statspack 包 提供 了 modify_statspack_parameter 过 程 来 修改 参数 的 值 。 针 对 每 个 参数 ， 存 储 过 程 
都 有 一 个 输入 参数 。 比 如 ， 以 下 调用 将 快照 级 别 更 改 为 6: 


statspack.modify statspack parameter(i snap level => 6) 


5.3.3 ”捕获 和 清除 快照 


你 可 以 调用 statspack 包 下 的 snap 子 程序 来 捕获 快照 。 包 下 有 两 个 子 程序 : 一 个 函数 和 一 个 存储 过 
程 。 它 们 都 可 以 指定 前 面部 分 介绍 的 任意 一 个 配置 参数 。 所 有 的 参数 都 是 可 选 的 ， 因 此 可 以 不 指定 任 
何 参 数 而 捕获 快照 ， 比 如 下 面 这 样 : 

perfstat.statspack. snap(); 


只 要 不 是 被 定义 成 基线 的 快照 ， 都 可 以 使 用 statspack 包 下 的 purge 子 程序 来 清除 。 包 下 一 共有 八 
个 子 程序 。 一 方面 ， 函 数 和 过 程 执行 着 同样 的 功能 。 另 一 方面 ， 有 四 种 方法 可 用 来 指定 清除 快照 ; 

口 指定 起 始 和 结束 快照 ID 之 间 的 所 有 快照 ( 参数 i_begin_snap 和 i_end_snap ); 

口 指定 开始 和 结束 时 间 之 间 的 所 有 快照 ( 参数 i_begin_date 和 i_end_date ); 

口 指定 某 一 时 间 之 前 的 所 有 快照 ( 参数 i purge_before_date ); 

口 指定 超过 特定 天 数 的 所 有 快照 ( 参数 i_num_days )。 

注意 ， 默 认 情 况 下 不 会 清除 SQL 语句 和 执行 计划 的 数据 。 如 果 要 清除 这 些 数 据 ， 需 要 设置 参数 
i_extended_purge 为 TRUE 来 激活 extendedpurge。 比 如 ， 以 下 调用 会 清除 2014 年 4 月 之 前 的 所 有 快照 ( 包 
括 SQL 语 句 和 执行 计划 ): 

statspack.purge( 

i purge before date => to date('2014-04-01','YYYY-MM-DD'), 


i extended purge => TRUE 
); 


鉴于 快照 不 能 自动 捕获 也 无 法 在 特定 时 间 后 清除 ， 所 以 需要 计划 两 个 任务 来 执行 这 些 操 作 。 请 看 
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下 面 的 例子 ( 注意 ， 两 个 任务 都 应 由 perfstat 用 户 来 创建 )。 
口 每 隔 15 分 钟 捕获 一 次 快照 。 


dbms_scheduler.create job( 
job_name => 'TAKE STATSPACK _ SNAPSHOT', 


job_type => 'PLSQL BLOCK'"， 

job action => "perfstat.statspack.snap();', 

start date => sysdate, 

repeat interval => 'FREQ = HOURLY; BYMINUTE = 0,15,30,45', 
enabled aS, TRUE, 

comments => 'take STATSPACK shapshot 


渡 
口 清除 创建 超过 35 天 的 快照 。 


dbms_scheduler.create job( 


job_name => "PURGE STATSPACK SNAPSHOTS', 
job type =>“PLSOL BLOCK’, 
job action => 'statspack.purge(i num days => 35, i extended purge => TRUE);', 
start date => Sysdate, 
repeat interval => 'FREQ = HOURLY; BYMINUTE = 50 ， 
enabled = TRUE, 
comments => 'purge STATSPACK shapshots 
); 


可 以 在 spauto.sql 和 sppurge.sql 脚 本 中 找到 Oracle 提 供 的 其 他 例子 。 要 获取 这 两 个 脚本 ， 可 查找 
$0RACLE_HOME/rdbms/admin 目 录 。 


注意 在 RAC 环 境 下 ， 需 要 在 每 个 数据 库 实例 上 分 别 计划 任务 。 


5.3.4 ”管理 基线 


为 常规 快照 设置 标记 ， 标 记 上 baseline 的 快照 是 基线 。 因 此 ， 它 不 同 于 删除 处 理 。statspack 包 提 
供 了 两 组 存储 过 程 和 函数 来 管理 这 些 标记 。 第 一 组 由 make_baseline 的 子 程序 组 成 , 用 来 为 一 个 或 多 个 
快照 设置 标记 。 第 二 组 由 clear baseline 的 子 程序 组 成 ， 用 来 为 一 个 或 多 个 快照 取消 标记 。statspack 
包 提供 了 同样 功能 的 函数 和 存储 过 程 。 唯 一 的 区 别 是 ， 函 数 会 返回 标记 修改 的 快照 数量 。 可 以 指定 一 
系列 ID 或 一 段 时 间 来 确定 需要 修改 的 快照 ,例如 , 以 下 调用 会 标记 两 个 指定 时 间 戳 之 间 的 快照 为 基线 : 
perfstat.statspack.make baseline( 
i begin date => to date('2014-04-02 17:00:00','YYYY-MM-DD HH24:MI:SS'), 
i end date => to date('2014-04-02 17:59:59','YYYY=-MM-DD HH24:MI:SS') 
); 
基于 同样 的 方法 ， 以 下 调用 会 取消 两 个 指定 时 间 惟 之 间 的 所 有 快照 标记 : 
perfstat.statspack.clear baseline( 
i begin date => to date('2014-04-02 00:00:00','YYYY-MM-DD HH24:MI:SS'), 
i end date => to date('2014-04-02 23:59:59','YYYY-MM-DD HH24:MI:SS') 
); 


140 第 5 章 不 可 重 现 问题 的 事后 分 析 


5.4 使 用 Diagnostics Pack 进行 分 析 


要 使 用 Diagnostics Pack 进 行 分 析 ， 建 议 使 用 Enterprise Manager 的 performance 页 面 ( 这 与 你 使 用 的 
是 Database Control 、Grid Control 还 是 Cloud Control 无 关 )。 正 如 第 4 章 描述 的 那样 ，Performance Home 
和 Top Activity 页 面 显 示 实 时 和 历史 信息 。 鉴于 本 章 旨 在 分 析 发 生 过 的 性 能 问题 , 所 以 会 用 到 历史 信息 。 
在 这 种 模式 下 ， 默 认 情 况 下 信息 可 以 保留 一 周 。 
历史 信息 分 析 与 实时 数据 分 析 基 本 相同 。 因 此 ， 详 细 信息 请 参考 第 4 章 。 这 里 主要 介绍 两 者 的 不 
同 之 处 。 
口 利用 历史 数据 ， 显 示 在 30 分 钟 间隔 里 ( 不 是 5 分 钟 ) 数据 库 负 载 的 详细 信息 。( 想 要 更 灵活 ， 
可 以 使 用 ASH Analytics )。 
口 由 于 不 是 所 有 实时 数据 都 保存 在 AWR 中 ， 因 此 数据 会 缺少 详细 信息 ， 甚 至 缺失 详细 信息 。 不 
过 你 可 以 访问 到 足够 多 的 关于 最 高 负载 的 信息 。 
口 无 法 搜索 特定 的 会 话 。 实 际 上 ，Performance 菜 单 里 的 Search Sessions 选 项 不 可 用 。 会 话 只 能 通 
过 Top Sessions 表 访问 。 
除了 Enterprise Manager 集 成 的 部 分 ，AWR 提 供 了 一 系列 报告 用 来 评估 指定 的 时 间 段 内 的 负载 情 
况 。 下 面 是 三 个 最 常用 的 报告 。 
口 AWR 报 告 总 结 了 一 段 时 间 内 指定 的 操作 。 这 个 报告 可 以 由 Enterprise Manager 生 成 ， 也 可 以 执 
行 $ORACLE_HOME/rdbms/admin/awrrpt.sql 脚 本 来 实现 。 鉴 于 该 报告 基于 Statspack 报 告 ， 请 参考 
下 一 部 分 中 关于 它 的 解释 信息 。 
口 周期 对 比 报告 对 比 两 个 指定 的 独立 时 间 段 。 这 对 找 出 数据 库 引 擎 经 历 性 能 问题 的 时 间 段 与 基 
线 时 间 段 之 间 的 区 别 非 常 有 用 。 这 个 报告 可 以 由 Enterprise Manager 生 成 ， 也 可 以 通过 执行 
$0RACLE_HOME/rdbms/admin/awrddrpt.sql 肢 本 来 实现 。 
口 SQL 语 句 报 告 提 供 关 于 SQL 语 句 的 详细 信息 。 更 多 信息 请 参考 第 10 章 ,特别 是 10.1.3 节 。 
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如 果 不 关注 单条 SQL 语 句 , 那 么 ,借助 Statspack, 通 过 执行 $4ORACLE_HOME/rdbms/admin/spreport.sql 
脚本 可 开始 对 性 能 问题 的 分 析 。 脚 本 在 询问 生成 报告 的 时 间 段 (我 建议 选择 两 个 连续 的 快照 ) 之 后 会 
把 报告 写 入 一 个 输出 文件 中 。 尽管 这 部 分 的 目标 是 介绍 如 何 阅 读 报告 ， 但 是 要 做 到 面面俱到 也 是 不 可 
行 的 。 实 际 上 ,报告 不 仅 非常 长 (一般 有 2000~3000 行 )， 并 且 可 能 包含 许多 大 部 分 时 间 都 不 需要 去 关 
注 的 内 容 。 很 多 内 容 只 是 为 了 应 对 不 时 之 需 。 


提示 AWR 是 Statspack 的 进化 版 ， 因 此 对 Statspack 报 告 的 解释 阅读 也 同样 适用 于 AWR 报 告 : 
分 析 从 报告 的 最 初 部 分 开始 ( 大 约 100 行 )。 这 部 分 信息 排列 得 不 是 特别 好 , 也 不 是 很 有 趣 。 然 而 ， 


由 于 报告 的 最 初 部 分 不 是 很 长 ， 却 也 值得 去 阅读 。 
Statspack 报 告 首先 介绍 了 实例 和 承载 服务 需 的 自述 信息 。 
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Database DB Id Instance Inst Num Startup Time Release RAC 


rorvrvrsrvrurv 


2532911053 DBM11203 1 23-Apr-14 16:33 11.2.0.3.0 NO 
Host Name Platform CPUs Cores Sockets Memory (6) 
helicon Linux x86 64-bit 8 8 2 7.8 


对 于 上 面 的 摘要 ， 请 记 住 数据 库 服务 器 的 CPU 核 数 。 稍 后 ， 这 一 信息 会 用 来 评估 数据 库 引 擎 是 否 
是 CPU bound。 


警告 ” 当 数 据 库 服务 器 配置 同步 多 线程 CPU 时 ，v$osstat 视 图 的 NUM CPUS 的 值 ( 也 是 Statspack 报 告 中 
的 CPUs 列 的 值 ) 会 被 设 成 线程 总 数 。 注 意 使 用 线程 数 来 评估 数据 库 是 否 为 CPU bound 会 造成 误 
导 。 实 际 上 ，100% 使 用 所 有 线程 是 不 可 能 的 。 即 使 基于 CPU 核 数 的 检查 会 被 认为 太 过 保守 ， 
却 也 可 以 放心 地 使 用 (假如 你 无 法 在 虚拟 化 环境 下 这 么 做 )。 


报告 接 下 来 提供 了 指定 时 间 段 ( 开始、 结束 和 持续 时 间 ) 的 信息 ， 开 始 时 间 段 和 结束 时 间 段 内 的 
会 话 数 ， 在 11.1 版 本 之 后 还 会 有 DB time (106.55 ) 和 CPU 使 用 率 ( 28.35 )5 在 这 一 部 分 ， 需 要 仔细 查 
看 需要 分 析 的 时 间 段 内 的 报告 。 注 意 : 平均 活动 会 话 数 (7.1 ) 只 在 11.1.0.7 及 以 后 的 版 本 中 存在 ， 它 
是 DB time 除 以 elapsed time 的 值 。 


Snapshot Snap Id Snap Time Sessions Curs/Sess Comment 
Begin Snap: 548 23-Apr-14 18:30:40 57 工作 
End Snap: 549 23-Apr-14 18:45:40 59 [5 
Elapsed: 15.00 (mins) Av Act Sess: WAN 
DB time: 106.55 (mins) DB CPU: 28.35 (mins) 


报告 接 下 来 提供 了 最 重要 的 SGA 组 件 的 大 小 。 注 意 缓 冲 区 缓存 (buffer cache ) 或 共享 池 在 观测 的 
时 间 段 内 是 否 发 生 改变 ,如果 发 生 了 改变 , 那么 结束 时 间 的 值 也 会 显示 。 否则 , 就 像 下 面 的 例子 这 样 ， 
只 会 显示 开始 时 间 的 值 : 


Cache Sizes Begin End 
Buffer Cache: 728M Std Block Size: 8K 
Shared Pool : 260M Log Buffer: 7,992K 
接 下 来 会 看 到 大 量 的 度量 值 ， 包 括 每 秒 处 理 、 每 个 事务 处 理 以 及 每 次 执行 和 调用 的 度量 什 : 
Load Profile Per Second Per Transaction Per Exec Per Call 
DB time(s): 六 0.0 0.01 0.00 
DB CPU(s): 1.9 0.0 0.00 0.00 
Redo size: 392,163.4 1,928.3 
Logical reads: 406,805.1 2,000.3 
Block changes: 2,822.9 13.9 
Physical reads: 579:7 2.9 
Physical writes: 377.8 1.9 
User calls: 2,895.2 外 六 :这 


Parses: 0.6 0.0 
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Hard parses: 0.0 0.0 

W/A MB processed: QT 0.0 

Logons: 0.0 0.0 

Executes: .306041 6.7 

Rollbacks: 0.0 0.0 
Transactions: 203.4 


上 面 大 多 数 的 度量 值 无 法 直接 用 于 评估 数据 库 实例 是 否 存 在 性 能 问题 。 它 们 的 主要 目的 有 两 个 。 


第 一 ,让 我 们 对 负载 有 个 大 体 了 解 。 例如 , 在 上 面 的 例子 中 , 我 们 看 到 每 秒 事务 量 为 203.4， 并且 平均 
每 个 事务 发 生 了 6.7 次 执行 。 因此 可 以 知道 系统 正在 执行 某 些 操作 。 第 二 ,可 以 用 来 判断 系统 做 的 工作 
是 否 超过 预期 ， 并且 更 重要 的 是 ,可 以 用 这 些 值 与 基线 进行 对 比 。 不 过 ， 有 两 个 度量 值 可 以 用 来 直接 
判断 数据 库 实例 负载 ( 不 过 ， 这 两 个 值 在 10.2 版 本 中 不 存在 )。 


口 DB time Per Second (7.1 ) 与 平均 活动 会 话 数 相等 。 根 据 第 4 章 介 绍 的 经 验 法 则 ， 若 平均 活动 


会 话 数 与 CPU 内 核 个 数 ( 8 ) 相等 ， 可 以 认为 系统 相当 繁忙 。 


口 DB CPU per second ( 1.9 ) 告诉 你 实例 是 否 是 CPU bound。 实 际 上 ， 可 以 将 它 与 CPU 内 核 个 数 
(8 ) 作对 比 ， 进 而 判断 CPU 的 平均 使 用 率 。 本 例 数据 库 实例 仅仅 消耗 了 24% ( 1.9/8 x 100 ) 的 
CPU。 因 此 ， 如 果 服 务 器 上 没有 其 他 数据 库 实例 或 应 用 ,那么 CPU 完全 可 以 满足 负载 。 

报告 接 下 来 是 一 组 有 限 的 使 用 率 。 唯 一 明智 的 做 法 就 是 用 其 与 基线 对 比 来 判断 是 否 有 值 改变 : 


Instance Efficiency Indicators 


~ ~ 


Buffer Nowait %: 100.00 Redo NoWait %: 

Buffer Hit  %: 99.86 Optimal W/A Exec %: 100.00 

Library Hit  %: 100.01 Soft Parse %: 
Execute to Parse %: 99.96 Latch Hit %: 


Parse CPU to Parse Elapsd %: 103.03 % Non-Parse CPU: 


Shared Pool Statistics Begin End 
Memory Usage %: 66.47 66.55 
% SOL with executions>1: 71.80 71.85 
% Memory for SQL w/exec>1: 72.70 72.88 


接 下 来 的 部 分 显示 top 5 事件 的 资源 使 用 分 析 ( 包括 CPU 使 用 率 )。 简单 来 说 , 在 这 张 表 里 , DB time 


Top 5 Timed Events 


NN NN 


Event Waits 
db file sequential read 520,240 
CPU time 

log file sync 182,275 
log file parallel write 178,406 
read by other session 2,693 


与 AWR 报 告 相反 ，top 5 事件 的 列表 不 会 显示 等 待 级 别 ( 例如 ，User I/0 
Concurrency )。 如 果 看 到 一 个 事件 属于 选择 忽略 的 等 待 级别 ， 可 以 执行 以 下 查询 来 找到 它 : 


SQL> SELECT wait class 
2 FROM v$event name 


被 拆 分 以 显示 时 间 是 如 何 花费 的 。 例 如 ， 根 据 以 下 的 摘录 ，71.6% 的 时 间 花 在 了 单 块 读 上 : 


Avg %Total 


Call 


、System I/0、Commit 或 
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3 WHERE name = "db file parallel read'; 


WAIT_CLASS 


User I/0 
报告 接 下 来 给 出 操作 系统 级 别 的 CPU 使 用 率 信息 ( 注意 ， 直 到 11.1.0.6 版 本 ，Instance CPU 部 分 只 
提供 百分比 值 并 且 使 用 不 同 的 标签 ): 


Host CPU (CPUs: 8 Cores: 8 Sockets: 2) 
A Load Average 


Begin End User System Idle WIO WCPU 
5.98 7.09 23.83 0.89 74.75 21.86 
Instance CPU 
RAR % Time (seconds) 
Host: Total time (s): 7;001,.7 
Host: Busy CPU time (s): 1,768.2 
% of time Host is Busy: 25.3 
Instance: Total CPU time (s): 1,739.9 
% of Busy CPU used for Instance: 98.4 
Instance: Total Database time (s): 6,500.3 
%DB time waiting for CPU (Resource MgT) : = 0.0 
上 面 的 摘录 有 以 下 两 个 目的 。 


口 确认 主机 (不 是 数据 库 实 例 ) 是 否 是 CPU bound。% of time Host is Busy 值 提供 了 你 需要 的 
信息 。 如 果 这 个 值 低 ( 比如 本 例 )， 那 就 没 问 题 。 如 果 该 值 高 ( 接近 100%， 前提 是 CPU 没 有 使 
用 同步 多 线程 )， 那 么 top 5 事件 的 资源 使 用 分 析 和 其 他 等 待 事件 的 统计 信息 会 造成 误导 。 实 际 
上 , 在 CPU 不 足 的 案例 中 , 许多 统计 值 会 被 人 为 提高 。 因 此 , 首要 目标 是 找 出 方法 来 降低 CPU 
使 用 率 。 

口 确认 操作 系统 级 别 的 CPU 使 用 率 是 否 主要 源 于 所 分 析 的 数据 库 实例 。 当 服务 器 上 运行 多 个 数 
据 库 实例 或 其 他 应 用 时 ， 这 是 一 个 重要 信息 。 最 需要 检查 的 值 是 % of Busy CPU used for 
Instance, 该 值 显 示 总 CPU 使 用 率 中 有 多少 是 由 于 你 正在 查找 的 数据 库 实例 所 导致 的 。 如 果 该 
值 低 于 80%~90%， 表 示 有 其 他 应 用 占用 了 过 多 的 CPU。 例如， 在 之 前 的 摘要 中 ， 数 据 库 实例 
几乎 使 用 了 所 有 的 CPU ( 98.4% )。 这 代表 这 台 服 务 器 上 没有 其 他 应 用 在 占用 过 多 的 CPU， 

操作 系统 级 别 的 CPU 使 用 率 信息 之 后 ， 是 操作 系统 级 别 的 内 存 使 用 率 信息 。 通 过 它 可 以 知道 在 主 

机 上 有 多 少 内 存 可 用 (8 GB ) 以 及 数据 库 实例 分 配给 SGA 和 PGA 的 百分比 (15.1% )。 


Memory Statistics Begin End 
Host Mem (MB): 7,974.6 7,974.6 

SGA use (MB): 1,019.4 1,019.4 

PGA use (MB): 175»1 183.1 

% Host Mem used for SCA+POA: 15.0 5: 


前 100 行 最 后 提供 的 是 时 间 模 型 统计 信息 。 正 如 第 4 章 讨论 过 的 那样 ,基于 这 些 数据 ， 可 以 知道 数 
据 库 引 擎 处 理 关 键 操作 花费 的 总 时 间 。 在 接 下 来 的 例子 中 ,统计 信息 显示 大 部 分 时 间 (95.5% ) 是 用 
来 执行 SQL 语句 。 
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Statistic Time (s) % DB time 
sql execute elapsed time 6,103.6 95.5 
DB CPU 1; YQ 26.6 
parse time elapsed 26.8 .4 
Sequence load elapsed time 0.1 .0 
PL/SQL execution elapsed time 0.0 :0 
repeated bind elapsed time 0.0 .0 
DB time 6,392.9 

background elapsed time 107.5 

background cpu time 38.8 


基于 报告 前 100 行 提供 的 信息 ， 应 该 可 以 对 当前 数据 库 有 一 个 相对 清晰 的 了 解 ， 比 如 ， 系 统 加 载 
的 范围 和 执行 的 主要 操作 ,下 一 步 是 找 出 top SQL 语句 。 出 于 此 目的 ,报告 会 包含 多 个 按 不 同 条 件 ( CPU、 
elapsed time、 风 辑 读数 、 物 理 读数 、 执 行 数 和 解析 调用 数 ) 排序 的 列表 。 鉴于 在 大 多 数 情况 下 ，elapsed 
time 是 最 重要 的 指标 ， 所 以 建议 根据 SQL ordered by Elapsed time 部 分 继续 分 析 。 

在 查看 列表 之 前 , 需要 确认 捕捉 到 的 SQL 语 句 是 否 占用 DB time。 如 果 像 下 面 引 用 的 部 分 一 样 , 捕 
捉 到 的 SQL 语 句 占用 了 大 部 分 的 DB time ( 95.4% )， 那 么 这 个 列表 就 包含 有 用 信息 : 


-> Total DB Time (s): 6,393 
-> Captured SQL accounts for 95.4% of Total DB Time 
-> SQL reported below exceeded 1.0% of Total DB Time 


然而 ， 万 一 捕捉 到 的 SQL 语 句 只 占 了 DB time 的 很 小 百分比 ( 比如 ，10%~20% )， 那 么 这 个 列表 用 
处 就 不 大 了 。 实际 上 , 要 么 占用 大 量 DBtime 的 SQL 语句 在 快照 捕获 前 被 清 出 了 库 缓 存 , 要 么 就 是 不 存 
在 占用 大 量 DB time 的 SQL 语句 。 如 果 是 前 者 , 那么 知识 库 没 有 包含 足够 的 信息 来 完成 分 析 。 如 果 是 后 
者 ,那么 没有 单独 哪 条 SQL 语句 占用 了 过 高 的 DBtime。 因 此 ， 正 如 4.1 节 所 述 ， 关 注 top SQL 语句 是 没 
有 意义 的 。 

如 接 下 来 的 引用 所 示 ， 对 于 每 条 SQL 语句 ， 不 仅 可 以 看 到 总 计 和 平均 的 elapsedtime， 也 可 以 看 到 
CPU 使 用 率 和 物理 读 : 


Elapsed Elap per CPU Old 
Time (s) Executions Exec (s) %Total Time (s) Physical Reads Hash Value 
1861.91 124,585 0.01 29.1 32.06 194,485 3739063178 
Module: Swingbench User Thread 
select customer id, cust first name ,cust last name ,nls languag 
e ,nls territory ,credit limit ,cust email ,account mgr id from 
Customers where customer id = :1 
1354.48 7,087 0.19 21.2 1241.76 7,834 1481390170 
Module: Swingbench User Thread 
SELECT /*+ first rows index(customers, customers pk) index(orde 
rs, order status ix) */ o.order id, line item id, product id, u 
nit price, quantity, order mode, order status, order total, sale 
s rep id, promotion id, c.customer id, cust first name, cust las 


648.93 36,705 0.02 10.2 20.58 70,411 3476971243 
Module: Swingbench User Thread 
insert into orders(ORDER ID, ORDER DATE, CUSTOMER ID, WAREHOUSE_ 
iD) values (一 下 二】 
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如 果 正 如 上 面 的 引用 那样 , 一 小 部 分 SQL 语 句 占用 了 大 量 的 DB time (前 三 个 SQL 语 句 占用 了 超过 
60% 的 DB time ), 那么 就 需要 找到 这 些 SQL 语 句 。 然 后 基于 散 列 值 , 使 用 sprepsql.sql 脚 本 来 获取 SQL 
语句 的 所 有 可 用 信息 ( 请 参考 第 10 章 ， 特 别 是 10.1.3 节 )。 

报告 的 其 他 部 分 可 以 用 来 获取 特定 的 行为 或 系统 配置 的 更 多 详细 信息 。 例如， 在 这 部 分 介绍 的 一 
个 场景 中 , 系统 是 disk IO bound, 针对 每 个 磁盘 IO 操作 相关 的 top event, 应 该 检查 Wait Event Histogram 
部 分 的 直方 图 。 基 于 直方 图 和 IO 子 系统 的 配置 ， 就 能 够 判断 磁盘 IO 操作 是 否 与 预期 一 致 。 根 据 以 下 
引用 ， 可 以 发 现 日 志 写 人 总 少 于 1 毫秒 。 而 读 取 速度 却 慢 得 不 止 一 个 数量 级 。 


Total ----------------- % of Waits ------------------ 
Event Waits 《lms <2ms “4ms 《8ms <“16ms <32ms 《=1S  »1s 


db file sequential read 520K 2.1 2.9 19.8 49.1 18.2 4.4 3.4 
log file parallel write 178K 98.7 号 .3 , 昌 3 流 水 


5.6 小 结 


本 章 介绍 了 Oracle 数 据 库 为 了 分 析 发 生 过 的 性 能 问题 所 提供 的 两 种 知识 库 AWR 和 Statspack， 以 及 
其 安装 、 配 置 和 管理 。 此 外 ， 还 概括 介绍 了 如 何 阅读 Statspack 报 告 ( 与 AWR 报 告 十 分 相似 )。 这 些 是 
本 章 你 应 该 掌握 的 主要 内 容 。 EE 

通常 情况 下 ,我 们 的 目的 不 是 调查 性 能 问题 ,而 是 在 第 一 时 间 避 免 它 。 根 据 我 的 经 验 ， 性 能 问题 
主要 有 两 种 起 因 : 设计 数据 或 应 用 时 没有 考虑 性 能 问题 ， 以 及 糟糕 的 查询 优化 器 配置 。 而 后 者 尤为 关 
键 ， 因 为 数据 库 引 擎 执行 的 每 条 SQL 语句 都 会 经 过 查询 优化 器 。 因 此 ， 第 三 部 分 不 仅 会 解释 查询 优化 
器 的 工作 原理 ， 还 会 介绍 如 何 正 确 配置 查询 优化 器 。 


Part 了 re 
查询 优化 器 


尽 人 事 ， 听 天 命 。 3 
一 一 爱 比 克 泰 德 n (Epictetus) 


发 送 到 数据 库 的 每 个 SQL 语句 在 由 SQL 引擎 处 理 之 前 都 要 转化 成 执行 计划 。 事 实 上 ， 应 
用 程序 只 是 通过 SQL 语句 指定 了 什么 样 的 数据 必须 处 理 ， 而 未 指定 如 何 处 理 。 查 询 优化 器 的 目 
标 不 仅 是 提供 执行 计划 来 描述 如 何 处 理 数 据 ， 同 时 最 重要 的 是 ， 交 付 高 效 的 执行 计划 = 如果 做 
不 到 这 一 点 可 能 会 导致 糟糕 的 性 能 。 也 正 因 如 此 ， 有 关 数 据 库 性 能 的 书 必须 涉及 查询 优化 器 。 

但 是 ， 这 部 分 的 目标 并 不 是 讲述 查询 优化 占 的 内 部 工作 机 制 。 相 反 , 这 里 会 呈现 一 个 非常 
实际 的 方法 ， 针 对 你 必须 了 解 的 查询 优化 器 的 基本 特征 进行 讲述 。 第 6 章 介绍 查询 优化 器 的 基 
本 概念 和 体系 结构 。 第 7、8 章 讨 论 查询 优化 器 使 用 的 统计 信息 。 第 9 章 描述 影响 查询 优化 央行 
为 的 初始 化 参数 以 及 如 何 设置 它们 。 最 后 ,第 10 章 概述 获取 执行 计划 的 不 同方 法 ,同时 也 介绍 
如 何 阅 读 它们 并 识 别 出 低 效 的 计划 。 

在 Oracle 数据 库 中 ， 提 供 两 个 主要 的 查询 优化 器 : 基于 规则 的 优化 器 (RBO) 和 基于 成 本 
的 优化 器 (CBO )。 从 Oracle Database 10g 开始 ， 已 经 不 再 支持 基于 规则 的 优化 器 ,， 所 以 我 们 不 
会 涵盖 这 部 分 内 容 。 在 本 书 中 ; 谈 到 查询 优化 器 这 个 术语 上 时， 始终 指 的 是 基于 成 本 的 优化 器 。 


OD http://www.quotationspage.com/quote/2525.html 
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查询 优化 器 是 SQL3 引 擎 的 构成 组 件 之 一 。 它 的 用 途 是 及 时 提供 高 效 的 查询 计划 。 时 间 约 束 至 关 重 
要 ， 因 为 大 多 数 情况 下 在 优化 阶段 花费 过 多 时 间 都 是 不 明智 的 。“ 过 多 时 间 ” 是 什么 意思 ? 通常 来 讲 ， 
包含 查询 优化 器 执行 工作 的 解析 阶段 ， 应 该 要 比 执行 阶段 时 间 更 短 。 在 解析 阶段 比 执行 阶段 花费 更 长 
时 间 的 众多 情形 中 ,唯一 可 以 接受 的 是 当 一 个 游标 可 以 被 多 次 执行 重用 时 。 正 如 在 第 2 章 中 所 讨论 的 ， 
在 SGA 中 缓存 与 某 个 游标 关联 的 共享 SQL 区 的 能 力也 是 出 于 同样 的 目的 而 引入 的 。 

本 章 的 目的 是 概述 查询 优化 器 执行 工作 所 用 的 信息 ， 描 述 SQL 引 擎 的 体系 结构 ， 并 且 解 释 其 内 部 
组 件 是 如 何 交互 来 处 理 SQL 语 名 的。 同时 也 提供 了 查询 优化 器 中 查询 转换 实施 过 程 的 信息 。 


6.1 基础 知识 


要 选择 一 个 执行 计划 ， 查 询 优化 器 需要 回答 下 列 问题 。 

口 从 SQL 语句 引用 的 每 张 表 中 抽取 数据 的 最 优 访问 路 径 是 什么 ? 

口 要 扫描 即将 处 理 的 引用 表 的 数据 ， 哪 一 种 连接 方法 以 及 连接 顺序 是 最 优 的 ? 

口 在 SQL 语句 执行 过 程 中 ， 应 该 何 时 去 处 理 聚 集 或 排序 操作 ? 

口 使 用 并 行 处 理 是 否 有 益 ? 

然而 在 实践 中 查询 优化 器 并 不 会 直接 回答 这 些 问题 。 它 会 探索 所 谓 的 搜索 空间 来 寻求 最 优 的 执行 计 
划 ,， 搜索 空间 由 所 有 潜在 可 行 的 执行 计划 组 成 。 为 了 找 出 哪个 执行 计划 是 最 优 的 ,查询 优化 器 会 估算 若 
干 执行 计划 的 成 本 ,并 从 中 选择 成 本 最 低 的 那 一 个 。 举 例 来 说 ， 以 下 查询 的 搜索 空间 包含 一 百 多 种 可 能 
的 执行 计划 。 通 过 search_space.sql 这 个 脚本 能 够 重 现 其 中 的 157 种 。 它 们 的 成 本 从 20 一 直到 100 000 多 。 

SELECT * 


FROM t1 JOIN t2 ON t1.id = t2.t1 id 
WHERE t1i.n = 1 AND t2.n = 2 


因为 查询 优化 器 的 目标 是 尽 可 能 迅速 地 找 出 成 本 最 低 的 执行 计划 ， 除 了 最 简单 的 SQL 语句 ， 查 询 
优化 器 并 不 会 评估 所 有 的 执行 计划 ， 这 一 点 至 关 重 要 。 换 名 话说， 查询 优化 器 只 探索 搜索 空间 的 一 部 
分 。 简 而 言 之 就 是 基于 启发 式 的 选择 ， 查 询 优 化 器 从 评估 最 有 和 希望 的 执行 计划 开始 ， 然 后 考虑 其 他 的 
执行 计划 直到 成 本 最 低 的 那个 出 现 ， 或 者 探查 到 太 多 可 供 选择 的 执行 计划 。 它 实现 了 一 个 叫 作 分 支 定 
界 (branch-and-bound ) 的 算法 。 一 个 分 支 就 是 一 个 可 供 选 择 的 执行 计划 ( 例如 , 一 条 访问 路 径 或 者 一 
个 连接 方法 )， 而 边界 则 是 到 目前 为 止 找到 的 最 佳 执行 计划 的 成 本 ， 一 旦 发 现 当前 分 支 的 成 本 比 边界 
高 ， 查 询 优化 器 就 会 尽快 丢弃 它 ( 并 很 可 能 连带 丢弃 其 所 有 子 分 支 ) 
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图 6-1 展 示 了 如 何 估算 一 个 执行 计划 的 成 本 , 查询 优化 器 不 仅 要 考虑 所 要 优化 的 SQL 语句 , 还 要 考 
虑 其 他 若干 输入 信息 。 其 中 有 些 输入 信息 存储 在 数据 字典 中 而 且 几 乎 很 少 改 变 ， 或 者 说 在 运行 时 不 期 
望 其 经 常 改变 。 当 应 用 程序 运行 时 可 以 认为 它们 是 静态 的 环境 变量 。 而 另外 的 一 些 输入 项 不 仅 可 能 会 
经 常 改变 ， 甚 至 每 次 执行 时 都 会 改变 ， 还 可 能 直到 运行 时 之 前 都 不 知道 是 否 会 改变 。 正 因为 这 些 输入 
项 ， 对 于 一 条 给 定 的 SQL 语句 ， 查 询 优 化 器 可 能 在 每 次 处 理 时 都 产生 一 个 新 的 执行 计划 。 


SQL 语句 
Ai 
半 象 统计 信息 绑 定 恋 
约 来 。 Ea 查询 优化 器 2 二 二 人 
理 设 
“执行 计划 


图 6-1 查询 优化 器 参考 若干 输入 项 来 产生 执行 计划 


图 6-1 中 的 一 些 输入 项 是 用 来 判定 哪些 选项 是 可 用 的 。 其 他 的 用 来 估算 潜在 执行 计划 的 成 本 。 下 面 
的 列表 简要 描述 了 这 些 输 入 项 ， 并 指出 了 本 书 的 哪些 部 分 提供 关于 它们 的 详细 信息 。 

口 系统 统计 信息 : 查询 优化 器 必须 知道 它 所 运行 的 系统 的 能 力 才能 提供 精确 的 估算 。 为 此 ， 系 
统统 计 信息 既 描述 运行 数据 库 引 擎 的 机 器 ， 同 时 也 给 出 存储 子 系统 的 性 能 指标 。 第 7 章 介绍 了 
有 哪些 系统 统计 信息 可 用 ， 如 何 管理 它们 ， 以 及 查询 优化 器 如 何 利用 它们 来 改进 估算 。 

口 对 象 统计 信息 : 表 、 索 引 以 及 列 统计 信息 ， 这 些 存储 在 数据 字典 中 的 信息 很 关键 ， 因 为 它们 
描述 了 存储 在 数据 库 中 的 数据 情况 。 例 如 ， 仅 仅 知道 将 要 处 理 的 SQL 语句 和 引用 对 象 的 结构 ， 
查询 优化 器 无 法 提供 高 效 的 执行 计划 。 为 了 产生 高 效 的 执行 计划 ,查询 优化 器 必须 能 够 量化 
所 要 处 理 的 数据 总 量 ， 还 要 知道 通过 各 种 不 同 的 可 选项 对 数据 进行 处 理 的 成 本 。 第 8 章 描述 了 
有 哪些 对 象 统计 信息 可 以 使 用 ， 以 及 如 何 管理 它们 。 

口 约束 : 查询 优化 器 利用 非 空 约束 、 唯 一 键 约束 、 主 键 约束 、 外 键 约束 以 及 一 些 检查 约束 。 本 章 
稍 后 会 讲述 ,约束 对 于 评估 应 用 特定 的 查询 转换 是 否 有 可 能 或 者 是 否 合理 也 很 关键 。 此 外 ， 因 
为 这 些 原 因 ， 在 定义 存储 在 数据 库 中 的 对 象 时 ， 要 创建 所 有 已 知 的 约束 ， 这 样 做 是 很 明智 的 。 

口 物理 设计 : 有 三 个 主要 的 物理 设计 领域 对 查询 优化 器 有 影响 。 第 一 ，Oracle 数 据 库 提供 了 五 种 
存储 数据 的 策略 : 堆 组 织 表 ( 默认 表 类 型 )、 索 引 组 织 表 、 外 部 表 、 索 引 聚 徐 和 散 列 聚 徐 。 另 
外 ， 堆 组 织 表 和 索引 聚 簇 可 以 进行 分 区 。 每 种 策略 都 有 一 条 或 多 条 访问 路 径 与 之 关联 。 第 13 
章 会 详细 介绍 这 些 访问 路 径 。 第 二 ， 对 于 除了 外 部 表 以 外 的 每 种 策略 ，Oracle 数 据 库 都 可 以 处 
理 多 种 类 型 的 索引 。 每 种 索引 类 型 ( 参见 第 13 章 ) 都 会 增加 具体 的 访问 路 径 。 此 外 ， 所 有 的 
存储 策略 都 支持 物化 视图 ， 以 便 通 过 查询 重 写 给 予 查询 优化 器 额外 的 途径 来 优化 查询 。 这 个 
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主题 会 在 第 1$ 章 中 进行 讨论 。 第 三 ， 即 使 列 顺序 并 不 影响 访问 路 径 . 但 是 会 影响 查询 优化 器 
的 一 些 成 本 的 计算 。 这 背后 的 原因 可 以 在 第 7 章 和 第 16 章 中 找到 答案 。 
口 SQL 控制 : 大 多 数 情形 下 ， 查 询 优化 器 能 够 生成 最 优 的 执行 计划 。 但 也 有 查询 优化 器 做 不 到 
的 例外 情况 ，Oracle 提 供 了 一 些 特性 来 改善 这 些 情况 出 现时 带 来 的 麻烦 。 第 11 章 会 详细 讨论 这 
些 特性 。 目 前 重要 的 是 , 要 知道 类 似 存 储 基线 、SQL 概 要 和 SQL 计 划 基 线 这 样 的 特性 允许 你 将 
它们 存 人 数据 字典 信息 中 ， 从 而 在 查询 优化 器 产生 执行 计划 时 影响 它 的 某 些 决定 。 
执行 环境 : 有 一 组 初始 化 参数 控制 着 查询 优化 器 的 行为 。 这 些 参数 通过 数据 库 引 擎 的 初始 值 
或 者 服务 器 参数 文件 SPFILE 设 置 在 系统 级 别 。 如 果 有 需要 , 这 些 参 数 可 以 通过 在 会 话 级 别 发 出 
ALTER SESSION 语句 来 覆盖 之 前 的 值 。 第 11 章 会 讲 到 其 中 的 一 部 分 甚至 可 以 在 SQL 语句 级 别 进 
行 更 改 。 有 些 参数 可 以 在 操作 系统 级 别 将 其 设置 在 服务 器 端 ， 也 可 以 设置 在 客户 端 。 国 家 语 
言 支 持 CNLS ) 参数 就 是 这 样 的 一 个 例子 ， 它 们 可 以 配置 在 连接 的 两 端 。 实 际 上 ，NLS 参 数 也 
可 以 通过 操作 系统 环境 变量 来 设置 , 或 者 在 Windows 上 通过 注册 表 设 置 。 特 别 是 在 客户 端 设 置 
时 ， 你 必须 很 小 心 : 对 于 客户 端 /服务 器 端的 应 用 ， 有 一 些 客户 端的 环境 变量 会 对 查询 优化 兢 
产生 影响 ， 这 一 点 经 常 被 忽略 。 第 9 章 会 讨论 控制 查询 优化 器 行为 的 最 重要 的 初始 化 参数 。 在 
第 13 章 中 会 涉及 一 部 分 NLS 参 数 。 
口 绑 定 变量 : 绑 定 变量 已 经 在 第 2 章 进 行 了 完整 的 介绍 。 除 了 值 以 外 ， 绑 定 变 量 的 定义 ( 也 就 是 
数据 类 型 ) 也 会 对 查询 优化 器 生成 执行 计划 造成 强烈 影响 。 
口 动态 采样 : 根据 存储 在 数据 字典 中 的 对 象 统 计 信 息 ， 查 询 优 化 器 并 不 总 是 能 够 精确 地 估算 出 
某 个 操作 或 者 谓词 的 成 本 。 当 查询 优化 器 识别 出 这 样 的 案例 ， 在 某 些 情形 下 它 能 够 在 执行 查 
询 优 化 期 间 动态 采集 额外 的 统计 信息 。 要 这 样 做 , 查询 优化 器 会 针对 待 优化 SQL 语 句 引 用 的 对 
象 执行 递归 查询 。 这 一 特性 会 在 第 9 章 中 进行 介绍 。 
口 基数 反馈 〈 也 称 为 统计 信息 反馈 ): 不 管 是 因为 复杂 的 谓词 还 是 缺少 输入 信息 ， 查 询 优化 器 并 
不 总 是 能 够 进行 精确 的 估算 。 当 查询 优化 器 意识 到 它 正 在 为 一 个 SQL 语句 进行 低 质量 的 估算 ， 
那么 生成 的 执行 计划 会 带 有 注解 。 在 SQL 语句 执行 完毕 后 会 对 估算 的 准确 性 进行 检查 。 如 果实 
际 值 和 估算 值 差异 明 显 ， 正 确 的 值 的 信息 就 会 被 存储 ， 并 在 SQL 语句 下 次 执行 时 强制 再 优化 。 
注意 再 优化 会 强制 查询 优化 器 利用 第 一 次 执行 时 获得 的 信息 ， 进 而 增加 了 生成 最 优 执行 计划 
的 机 会 。 这 个 特性 仅 从 11.2 版 本 起 可 用 。 
使 用 的 Oracle 数 据 库 软件 的 版 本 也 会 决定 哪些 查询 优化 器 的 特性 可 用 。 要 清楚 认识 到 ， 即 便 知道 
了 Oracle 数 据 库 版 本 的 五 位 数字 ， 对 于 完全 了 解 哪些 特性 可 用 也 是 不 够 的 。 还 需要 知道 正在 使 用 的 版 
本 是 企业 版 还 是 标准 版 。 此 外 , 注意 , 某 些 补 丁 也 会 控制 特定 查询 优化 器 特性 的 可 用 性 以 及 其 的 行为 。 


6.2 ”体系 结构 


查询 优化 器 可 以 分 解 为 远 辑 优化 器 和 物理 优化 器 ， 它 只 是 SQL 引擎 的 一 个 构成 模块 。 


口 
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SQL 语 名 


系统 统计 信息 
人 


查询 优化 器 


图 6-2 SQL 引擎 的 体系 结构 


如 图 6-2 所 示 ， 以 下 是 SQL 引擎 的 关键 组 件 。 

口 解析 器 : 这 是 与 SQL 执行 有 关 的 第 一 个 组 件 。 它 的 用 途 是 向 查询 优化 器 传递 SQL 语句 解析 后 的 
形式 。 关 于 解析 器 执行 工作 的 更 多 信息 已 经 在 第 2 章 尤 其 是 2.4 节 中 介绍 过 。 

口 逻辑 优化 器 : 在 逻辑 优化 阶段 ， 查 询 优化 器 通过 应 用 不 同 的 查询 转换 技术 产生 新 的 语义 相等 
的 SQL 语句 。 逻 辑 优化 器 的 目的 是 选择 出 查询 转换 的 最 佳 组 合 。 在 这 种 情况 下 , 搜索 空间 增加 
了 ， 执 行 计 划 可 以 被 探索 而 不 会 被 认为 没有 经 过 这 样 的 查询 转换 。6.3 节 会 提供 关于 这 个 组 件 
执行 工作 的 额外 信息 。 

口 物理 优化 器 : 在 物理 优化 阶段 ， 执 行 了 几 项 操作 。 一 开始 ， 针 对 由 逻辑 优化 生成 的 每 个 SQL 
语句 生成 了 几 个 执行 计划 。 然 后 每 一 个 执行 计划 都 发 送 给 成 本 估算 器 让 其 计算 出 一 个 成 本 。 
最 后 ， 拥 有 最 低 成 本 的 那个 执行 计划 就 被 选中 了 。 简 单 地 说 ， 物 理 优化 器 探索 搜索 空间 来 找 
出 最 有 效率 的 执行 计划 

口 成 本 估算 器 : 根据 图 6-1 中 介绍 的 输入 项 , 成 本 估算 器 计算 由 物理 优化 器 提交 的 执行 计划 的 成 本 。 

口 行 源 生 成 器 : 查询 优化 器 生成 的 执行 计划 不 能 直接 由 执行 引擎 执行 。 它 必须 转化 成 行 源 操 作 
树 以 存储 在 库 缓存 中 ， 

口 执行 引擎: 这 个 组 件 执行 由 行 源 生 成 器 产生 的 行 源 操作 。 如 果 基 数 反馈 的 监控 是 激活 的 ， 执 
行 引 警 ( 执行 完毕 后 ) 会 校 验 实际 值 和 估算 值 的 差异 是 否 明 显 。 如 果 找 到 了 明显 差异 ， 关 于 
正确 值 的 信息 就 会 存储 到 共享 SQL 区 中 ,并 且 在 下 一 次 执行 中 ， 再 优化 是 强制 进行 的 。 
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6.3 查询 转换 


查询 优化 器 使 用 大 量 的 查询 转换 来 产生 新 的 语义 相等 的 SQL 语句 。 在 那些 查询 转换 中 ,根据 用 于 
决定 是 否 应 用 它们 的 方法 ， 可 以 分 为 两 种 途径 。 

口 基于 启发 式 的 查询 转换 ( Heuristic-based query transformations ) 是 在 满足 特定 条 件 时 应 用 的 。 

在 大 多 数 情 况 下 它们 预计 都 会 引出 更 好 的 执行 计划 。 
口 基于 成 本 的 查询 转换 ( Cost-based query transformations ) 是 根据 成 本 估算 器 计算 的 成 本 而 应 用 
的 ， 它 们 会 引出 与 原始 语句 相 比 成 本 更 低 的 执行 计划 。 

下 面 的 章节 介绍 了 二 十 几 种 查询 转换 并 提供 了 相应 的 用 例 。 目 的 不 是 对 这 些 转换 高 谈 阔 论 ， 而 是 
为 你 提供 一 些 头绪 去 了 解 在 逻辑 优化 阶段 引擎 内 部 都 发 生 了 什么 。 因 此 ， 没 有 给 出 关于 先决 条 件 或 限 
制 性 的 详细 信息 。 同 时 注意 一 些 查询 转换 实际 上 可 能 会 更 加 强大 ， 或 只 有 在 最 近 的 版 本 中 才 可 用 。 所 
以 ,， 并非 本 章 描述 的 每 种 查询 转换 在 早 前 的 版 本 中 都 可 用 ， 比 如 在 版 本 10.2 和 11.1 中 。 


注意 ”我 试图 让 接 下 来 的 例子 尽 可 能 简单 。 结 果 就 是 ， 乍 看 之 下 ， 某 些 查询 转换 似乎 只 有 在 处 理 劣 
质 的 SQL 语句 时 才 可 能 用 得 到 。 劣 质 的 意思 是 指 包含 多 余 或 冲突 操作 的 SQL 语句 。 但 你 必须 考 
虑 到 查询 优化 器 不 得 不 去 处 理 比 示例 中 要 复杂 得 多 的 SQL 语 和 句 , 试想 一 下 , 一 个 查询 引用 了 几 
个 视图 而 这 些 视图 又 引用 了 其 他 视图 的 情况 ,或 者 由 通用 用 途 的 工具 和 专门 的 查询 工具 生成 
的 查询 语句 。 当 查询 优化 器 把 所 有 的 东西 放 在 一 起 ， 出 现 多 余 或 冲突 操作 的 情况 会 展 见 不 鲜 
此 外 ， 查 询 优化 器 能 识别 奇怪 的 情况 并 避免 执行 不 必要 的 处 理 。 还 有 ， 一 些 查 询 转换 允许 你 
按 最 自然 、 可 读 的 方式 书写 SQL 语句 ， 而 不 用 为 性 能 牺牲 清晰 性 。 实际 上 ， 一 些 查询 转换 是 
非常 常见 的 SQL 优化 技术 ， 当 手工 应 用 时 5 会 产生 不 易 读 的 SQL 语句 。 


6.3.1 计数 转换 


计数 转换 ( Count Transformation ) 的 目的 是 将 count ( 列 ) 表达 式 转化 为 count(*)。 引 人 这 个 查询 
转换 是 因为 相 比 count ( 列 )， 处 理 count(*) 时 在 索引 使 用 方面 有 更 多 的 选择 空间 。 第 13 章 会 详细 讨论 
这 方面 的 内 容 。 计 数 转 换 基于 启发 式 的 查询 转换 ， 可 以 在 count 销 数 引 用 的 列 中 关联 NOT NULL 约 束 时 进 
行 应 用 (但 是 检查 约束 时 不 能 用 于 此 用 途 )。 注 意 计 数 转换 也 会 将 count(1) 这 样 的 表达 式 转 化 为 
count(*)。 

下 面 的 例子 基于 count_transformation.sql 脚 本 ， 阅 明了 这 种 查询 转换 。 注 意 原始 的 查询 包含 
count(n2) 这 个 表达 式 : 


SELECT count(n2) 
FROM +t 


如 果 有 一 个 NOT NULL 约 束 定义 在 n2 列 上 ， 计 数 转 换 就 会 将 count(n2) 转 换 为 count(*) 并 生成 以 下 查询 : 


SELECT count(*) 
FROM 七 
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6.3.2 ”公共 子 表达 式 消除 


公共 子 表达 式 消除 ( common sub-expression elimination ) 的 目的 是 移 除 重复 的 谓词 从 而 避免 多 次 
处 理 同一 个 操作 。 这 是 一 种 基于 启发 式 的 查询 转换 。 

下 面 的 例子 来 自 common_subexpr_elimination.sql 这 个 脚本 ， 注 意 两 个 分 隔 的 谓词 是 如 何 重 释 的 。 
实际 上 ， 所 有 满足 第 一 个 条 件 的 数据 行 都 满足 第 二 个 条 件 : 


SELECT * 
FROM 七 
WHERE (n1 = 1 AND n2 = 2) OR (nl = 1) 


公共 子 表达 式 消除 可 移 除 元 余 的 谓词 ， 并 产生 以 下 查询 : 
SELECT * 


FROM 七 
WHERE ni1 = 1 


你 是 不 是 对 留 下 的 谓词 感到 惊讶 ?如 果 仔 细 考 虑 一 下 ， 会 发 现 n1=1 足 以 满足 这 个 查询 了 ， 而 n2=2 
却 仍然 需要 考虑 n1=1 的 情况 。 


6.3.3 “或 扩张 


“或 ”扩张 ( or expansion ) 的 目的 是 将 查询 的 WHERE 条 件 中 包含 分 隔 谓词 的 语句 转化 为 使 用 一 个 或 
多 个 UNION ALL 集 合 运算 符 的 复合 查询 。 通 常情 况 下 ， 每 个 分 隔 的 谓词 被 转化 成 为 一 个 组 件 查询 。 这 里 
应 用 的 是 一 个 基于 成 本 的 查询 转换 ， 大 多 数 时候 是 为 了 启用 额外 的 索引 访问 路 径 。 实 际 上 ， 分 隔 的 谓 
闻 和 索引 在 一 起 搭配 时 并 不 总 是 进展 顺利 〈 参 见 第 13 章 )。 还 要 注意 仅 从 11.2.0.2 版 本 起 这 种 查询 转换 
才 开 始 支持 函数 式 索 引 。 


注意 即使 “或 ”扩张 是 基于 成 本 的 查询 转换 ， 查 询 优化 器 也 会 在 尝试 使 用 它 之 前 检查 一 些 启发 式 
查询 转换 。 如 果 查询 转换 不 被 允许 ， 可 能 会 错失 一 个 拥有 更 低 成 本 的 执行 计划 。 


接 下 来 的 例子 基于 or_expansion.sql 这 个 脚本 ,注意 ，WHERE 条 件 包含 两 个 分 隔 的 谓词 。 因 为 这 些 
原因 ， 查 询 优 化 器 会 评估 一 次 基于 表 扫 描 的 成 本 是 否 高 于 两 次 单独 的 基于 索引 扫描 的 成 本 : 


SELECT pad 
FROM t 
WHERE n1 = 1 OR n2 = 2 


如 果 两 次 索引 扫描 的 成 本 更 低 ,“ 或 ”扩张 就 会 产生 以 下 查询 。 注 意 ， 添 加 lnnvl(n1 = 1) 这 个 谓 
词 是 为 了 避免 多 重 记录 。lnnv1 函 数 在 作为 参数 传递 的 条 件 为 FALSE 或 NULL 时 返回 TRUE。 因 此 ， 第 二 个 
组 件 查 询 只 会 在 第 一 个 组 件 查 询 未 返回 某 条 记录 的 情况 下 才 返 回 这 条 记录 : 


SELECT pad 

FROM +t 

WHERE n1 = 1 

UNION ALL 

SELECT pad 

FROM +t 

WHERE n2 = 2 AND lnnvl(n1 = 1) 
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一 些 分 隔 的 谓词 永远 不 会 被 显 式 地 用 “或 ”扩张 转换 。 下 面 的 查询 就 展示 了 这 样 一 个 例子 。 所 有 
的 谓词 都 引用 了 一 个 叫 作 ni 的 列 ， 使 得 NHERE 条 件 的 内 容 能 够 像 IN 条 件 那 样 处 理 : 
SELECT * 


FROM 七 
WHERE ni1 = 1 OR ni1=2 ORnNn1=3 ORn1i=4 


6.3.4 视图 合并 


视图 合并 ( View Merging ) 的 目的 是 通过 合并 语句 中 一 部 分 视图 和 内 联 视 图 ， 以 便 减 少 由 它们 产 
生 的 查询 块 的 数量 。 引 入 这 个 查询 转换 的 原因 是 ， 如 果 没 有 它 ， 查 询 优化 器 就 会 分 别处 理 每 一 个 查询 
块 。 当 分 别处 理 每 个 查询 块 时 ， 查 询 优化 器 无 法 保证 每 次 都 为 整体 SQL 语 句 产生 最 优 的 执行 计划 。 此 
外 ， 由 视图 合并 产生 的 查询 块 可 能 会 进一步 引导 启用 其 他 的 查询 转换 。 


简单 地 说 ， 最 顶级 的 SQL 语句 以 及 一 个 SQL 语句 中 拥有 自己 的 SELECT 子 句 的 每 个 扩展 部 分 都 是 
查询 块 。 简 单 的 SQL 语句 只 有 一 个 单独 的 查询 块 。 而 一 旦 使 用 了 视图 或 者 像 子 查询 、 内 联 视图 以 及 
集合 运算 符 这 样 的 结构 ， 多 重 的 查询 块 就 出 现 了 。 例如 ， 下 栈 巾 要 的 帮主 个 泛 仙 次 4 护卫 国明 同业 
我 用 子 查询 分 解 子 句 代替 定义 一 个 真正 的 视图 )， 第 一 个 查询 块 是 顶层 查询 ， 就 是 引用 dept 表 的 那 
个 查询 。 第 二 个 查询 块 是 使 用 WITH 子 名 定义 的 查询 ， 它 引用 的 是 emp 表 : 

WITH emps AS (SELECT deptno, count(*) AS cnt 

FROM emp 
GROUP BY deptno) 
SELECT dept.dname, emps.cnt 


FROM dept, emps 
WHERE dept.deptno = emps.deptno 


【ee 
视图 合并 有 两 个 子 范畴 。 
口 简单 视图 合并 ( Simple view merging ) 用 于 合并 简单 的 选择 -投影 -连接 查询 块 。 因 为 它 所 处 
理 情 况 的 简单 性 ， 简 单 视图 合并 是 一 种 基于 启发 式 的 查询 转换 。 它 无 法 应 用 于 包含 类 似 聚 合 、 
合 运算 符 、 层 次 查询 、MODEL 子 名 或 者 SELECT 列表 中 含有 子 查 询 这 样 的 视图 或 内 联 视图 
口 复杂 视图 合并 ( Complex view merging ) 用 于 合并 包含 聚合 的 查询 块 。 这 是 一 种 基于 成 本 的 查 
询 转换 ， 无 法 应 用 于 有 层次 查询 出 现 或 者 包含 GROUPING SETS 、ROLLUP 、PIVOT 或 者 MODEL 子 句 的 
视图 或 内 联 视 图 。 
注意 ， 因 为 应 用 复杂 视图 合并 不 一 定 能 够 带 来 好 处 ， 所 以 它 是 基于 成 本 的 查询 转换 。 实 际 上 ,应 用 
它 时 , 物化 视图 或 者 内 联 视 图 中 出 现 的 聚合 就 被 推 后 了 , 因此 可 能 导致 SQL 在 一 个 很 大 的 结果 集 上 执行 


中 选择 -投影 -连接 查询 块 由 三 个 基本 操作 组 成 :一 个 选择 操作 用 于 抽取 满足 指定 谓词 的 记录 ， 一 个 投影 操作 从 引用 
的 表 中 抽取 指定 的 列 ， 还 有 一 个 连接 操作 将 不 同 表 中 抽取 的 数据 放 在 一 起 。 过 滤 和 连接 谓词 基于 类 似 等 号 这 样 的 
简单 运算 符 。 例 如 : SELECT t1,id, t2.n FROM t1 JOIN t2 ON t1.id = t2.id WHERE t1.n = 42 
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视图 合并 可 能 会 带 来 安全 问题 。 为 了 预防 这 些 问题 ， 就 提出 了 安全 视图 合并 的 概念 ， 并 由 初始 化 
参数 optimizer secure view merging 控 制 其 是 否 可 用 。 第 9 章 会 详细 讨论 这 个 特性 。 
1. 简单 视图 合并 
在 下 面 这 个 来 自 simple_view_merging.sql 脚 本 的 例子 中 ,查询 由 三 个 查询 块 构成 : 顶层 查询 和 两 
个 内 联 视图 。 注 意 ， 这 两 个 内 联 视图 是 简单 的 选择 -投影 -连接 查询 块 : 
SELECT 矶 
FROM (SELECT t1.* 
FROM 七 1， 七 2 
WHERE t1.id = t2.t1 id) t12, 
(SELECT * 
FROM +t3 


WHERE id > 6) t3 
WHERE 超 2 过 = ,td id 


因为 内 联 视 图 可 以 进行 合并 ， 简 单 视图 合并 产生 了 以 下 查询 : 

SELECY 2 

FROM t1; t2, t3 

WHERE t1.id = t3.t1 id AND t1.id = t2.t1 id AND t3.id > 6 

当 涉 及 外 链接 时 简单 视图 合并 就 不 一 定 每 次 都 能 执行 了 。 例如， 在 之 前 的 查询 中 ， 如 果 把 顶层 查 
询 的 谓词 改 成 t12.id =t3.t1 id(+)， 视 图 合并 仍 可 以 执行 ,但 是 如 果 将 谓词 改 成 tt2.id(+) = t3.t1 id 
就 没 法 执行 视图 合并 了 。 


2. 复杂 视图 合并 


下 面 的 例子 来 自 complex_view merging.sql 脚 本 ， 展 示 了 一 个 带 有 GROUP BY 子 名 的 内 联 视图 。 这 样 
的 查询 按 以 下 方式 执行 : 访问 内 联 视图 中 引用 的 表 , 评估 GROUP BY 子 句 和 sum 函 数 ， 最 后 将 内 联 视 图 的 
结果 集 与 顶层 查询 引用 的 表 进 行 连接 : 
SELECT t4.id, tt.ns tL1.pad, t2. 50m NW 
FROM t4, (SELECT n, sum(n) AS sum n 
FROM t2 


GROUP BY n) t2 
WHERE t1.n = t2.n 


将 GROUP BY 子 句 的 评估 推迟 直到 连接 完毕 之 后 有 利 时 ， 复 杂 视 图 合并 产生 以 下 查询 : 


SELECT t1.id, ti.n, ti.pad, sum(n) AS sum n 
FROM t1, t2 


WHERE t4n = 起 2 
GROUP BY t1.id, t1i.n, t1i.pad, t1.rowid, t2.n 


6.3.5 ”选择 列表 裁剪 


选择 列表 裁剪 (Select List Pruning ) 的 目的 是 移 除 不 必要 的 列 或 者 移 除 来 自 子 查询 、 内 联 视 图 以 
普通 视图 的 SELECT 子 句 的 表达 式 。 这 种 类 型 的 查询 转换 不 会 考虑 顶层 查询 的 SELECT 子 句 。 当 一 个 列 
或 者 表达 式 没 有 在 除 引 用 或 定义 它 的 SELECT 子 句 以 外 的 地 方 被 引用 时 ， 就 会 被 认为 是 没有 必要 的 。 这 
是 一 种 基于 局 发 式 的 查询 转换 。 
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在 下 面 这 个 来 自 select list_ pruning.sql 脚 本 的 例子 中 ， 注 意 ， 子 查询 引用 的 两 个 列 ( n2 和 n3 ) 
没有 被 外 层 的 主 查 询 引 用 : 
SELECT ni 
FROM (SELECT n1, n2, n3 
FROM +) 
因为 m2 和 n3 这 两 个 列 是 没有 必要 的 ， 选 择 列表 裁剪 会 移 除 它们 并 产生 以 下 查询 : 


SELECT n1 
FROM (SELECT n1 
FROM t) 


使 用 视图 合并 ， 可 以 进一步 简化 查询 。 于 是 生成 了 下 面 这 样 的 查询 : 


SELECT n1 
FROM t 


6.3.6 ”谓词 下 推 


谓词 下 推 ( Predicate Push Down ) 的 目的 是 将 谓词 下 推 到 无 法 合并 的 视图 或 内 联 视 图 的 内 部 。 能 
够 进行 下 推 的 谓词 必须 包含 在 拥有 不 可 合并 的 视图 或 内 联 视 图 的 查询 块 的 内 部 。 应 用 这 种 类 型 的 查询 
转换 有 三 个 主要 的 原因 : 

口 为 了 启用 额外 的 访问 路 径 ( 典型 的 是 索引 扫描 ); 

口 为 了 启用 额外 的 连接 方法 以 及 连接 顺序 ; 

口 为 了 确保 能 够 尽 可 能 快 地 应 用 谓词 ， 从 而 避免 不 必要 的 处 理 操作 。 

谓词 下 推 有 两 个 子 范畴 : 过 滤 谓 词 下 推 和 连接 谓词 下 推 。 两 种 变换 的 不 同 是 由 它们 操作 的 谓词 的 
类 型 决定 的 。 


1. 过 滤 谓 词 下 推 
过 滤 谓 词 下 推 ( Filter Push Down ) 的 目的 是 将 限制 条 件 ( 过 滤 条 件 ) 下 推 到 不 可 合并 的 视图 或 者 
内 联 视 图 的 内 部 。 这 是 一 种 基于 启发 式 的 查询 转换 。 注 意 ， 这 种 查询 转换 不 下 推 连 接 条 件 。 下 推 连接 
条 件 是 由 下 一 节 呈 现 的 查询 转换 完成 的 。 
下 面 的 例子 来 自 filter_push_down.sql 脚 本 。UNION 集 合 运算 符 用 来 防止 内 联 视图 与 顶层 查询 合并 : 
SELECT * 
FROM (SELECT * 
FROM t1 
UNION 
SELECT * 


FROM t2) 
WHERE id = 1 


过 滤 谓 词 下 推 将 限制 条 件 (id=1 ) 下 推 到 内 联 视图 的 内 部 并 产生 了 下 面 的 查询 。 现 在 ， 这 两 张 表 
不 仅 可 以 通过 索引 来 访问 ， 同 时 也 保证 了 UNION 集 合 运算 符 需 要 的 排序 操作 所 处 理 的 记录 尽 可 能 少 : 

SELECT * 

FROM (SELECT * 


FROM t1 
WHERE id = 1 
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UNION 

SELECT * 

FROM t2 

WHERE id = 1) 


此 外 简单 视图 合并 还 消除 了 顶层 查询 块 。 


2. 连接 谓词 下 推 


连接 谓词 下 推 ( Join Predicate Push Down ) 的 目的 是 将 连接 谓词 下 推 到 无 法 合并 的 视图 或 内 联 视 
图 的 内 部 。 这 是 一 种 基于 成 本 的 查询 转换 。 


下 面 的 例子 来 自 join_predicate_push_down.sql 脚 本。UNION 集 合 运算 符 用 来 防止 内 联 视 图 与 顶层 
查询 合并 。 注 意 ， 内 联 视图 与 上 一 节 例 子 中 所 用 的 是 一 样 的 ( 尽管 表 的 名 称 不 一 样 )。 只 不 过 在 本 例 
中 ， 内 联 视 图 与 男 外 一 张 表 进行 连接 : 


SELECT * 

FROM t1, (SELECT * 
FROM t2 
UNION 
SELECT * 
FROM t3) t23 

WHERE t1.id = t23.id 


连接 谓词 下 推 将 连接 条 件 ( t1.id = t23.id ) 下 推 到 内 联 视 图 的 内 部 并 产生 以 下 查询 。 这 个 查询 
享有 与 上 一 小 节 描 述 的 查询 相同 的 好 处 ( 启用 了 索引 访问 ,减少 了 需要 排序 的 数据 总 量 )。 在 这 个 例 
子 中 ， 额 外 的 访问 路 径 也 允许 查询 优化 器 自由 选择 所 有 可 用 的 连接 方法 和 连接 顺序 : 
SELECT * 
FROM t1, (SELECT * 
FROM t2 
WHERE t2.id = t1.id 
UNION 
SELECT * 
FROM t3 
WHERE t3.id = t1.id) t23 


尽管 前 面 的 SQL 语 句 并 不 是 有 效 的 ( t1.id 列 在 内 联 视 图 内 部 并 不 可 见 )， 但 是 SQL 引擎 可 以 处 理 
与 它 类 似 的 一 些 情 况 。 为 了 支持 这 样 的 查询 ， 从 12.1 版 本 开始 可 以 使 用 侧 向 内 联 视 图 。 例如， 下 面 的 
查询 在 12.1 版 本 中 是 合法 的 : 


SELRET 生 
FROM t1, lateral(SELECT * 
FROM t2 
WHERE t2.id = t1.id 
UNION 
SELECT 法 
FROM t3 
WHERE t3.id = t1.id) t23 
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6.3.7 ”谓词 迁移 


谓词 迁移 ( Predicate Move Around ) 的 目的 是 将 限制 条 件 (过滤 条 件 ) 提取 、 跨 越 、 下 推 到 无 法 
合并 的 视图 或 内 联 视图 的 内 部 。 尽 管 这 有 点 类 似 谓词 下 推 ， 这 个 查询 转换 还 能 将 谓词 在 彼此 不 包含 的 
查询 块 之 间 移 动 。 应 用 这 种 基于 启发 式 的 查询 转换 的 主要 原因 是 启用 额外 的 访问 路 径 (一 般 来 说 是 索 
引 扫描 ) 并 确保 谓词 能 够 尽 可 能 快 地 应 用 。 

下 面 例子 中 的 两 个 内 联 视图 来 自 redicate_move around.sql 脚 本 , 因为 DISTINCT 运 算 符 的 原因 不 能 
与 顶层 查询 合并 。 第 一 个 内 联 视图 在 用 于 两 个 内 联 视图 连接 条 件 (tl.n = t2.n) 的 列 Cn) 上 有 一 个 
限制 条 件 : 


SELECT t1.pad, t2.pad 

FROM (SELECT DISTINCT n, pad 
FROM t1 
WHERE n = 1) tl， 
(SELECT DISTINCT n, pad 
FROM t2) t2 

WHERE t1i.n = t2.n 


在 本 例 中 ， 谓 词 迁移 执行 以 下 三 个 主要 步 又 。 
(1) 将 限制 条 件 Cn = 1 ) 从 第 一 个 内 联 视 图 中 提取 到 顶层 查询 中 。 
(2) 在 限制 条 件 (t1.n = 1 ) 与 连接 条 件 (t1.n = t2.n ) 之 间 应 用 传递 特性 ， 从 而 产生 新 的 谓词 
(Eo = 
(3) 将 新 的 谓词 下 推 到 第 二 个 内 联 视 图 内 部 。 
结果 就 是 谓词 迁移 生成 了 接 下 来 的 查询 语句 。 将 谓词 添加 到 第 二 个 内 联 视图 内 部 ， 不 仅 允 许 通 过 
索引 访问 t2 表 ， 而 且 也 相应 地 减少 了 DISTINCT 运 算 符 需要 处 理 的 数据 总 量 : 
SELECT t1.pad, t2.pad 
FROM (SELECT DISTINCT n, pad 
FROM t1 
WHERE n = 1) t1, 
(SELECT DISTINCT n，pad 
FROM t2 


WHERE n = 1) t2 
WHERE ti.n = t2.n 


6.3.8 非 重复 放置 


非 重 复 放置 ( Distinct Placement ) 的 目的 是 尽快 消除 重复 。 这 种 基于 成 本 的 查询 转换 仅 从 11.2 版 本 
开始 起 才 可 用 。 

DISTINCT 运 算 符 的 作用 是 从 结果 集中 去 除 重复 。 当 它 在 查询 中 与 其 他 一 个 或 多 个 联接 一 同 被 指定 
时 ,从 概念 上 讲 , 数据 库 引擎 应 该 在 联接 处 理 完毕 后 再 处 理 DISTINCT 运 算 符 。 然 而 ， 要 达到 最 佳 性 能 ， 
在 某 些 情况 下 需要 在 处 理 联 接 之 前 消除 重复 。 更 早 消除 重复 可 以 保证 中 间 结 果 集 尽 可 能 小 ,这样 需要 
联接 处 理 的 数据 也 随 之 减少 了 。 

下 面 的 例子 来 自 distinct_placement.sql 脚 本 ， 在 两 张 表 中 存在 着 父 - 子 关系 。 进 一 步 来 说 ， 你 可 
以 假设 子 表 (t2 ) 比 父 表 (tl ) 包含 更 多 的 记录 : 
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SELECT DISTINCT ti.n, t2.n 
FROM t1，t2 
WHERE t1,id = t2.t1 id 


当 t2.n 的 不 同 值 的 数量 远 远 少 于 子 表 中 存储 的 数量 时 ， 非 重复 放置 就 产生 了 下 面 的 查询 。 注 意 额 
外 增加 的 DISTINCT 运 算 符 ， 它 应 用 于 子 表 的 数据 ， 在 联接 父 表 之 前 就 消除 了 重复 : 


SELECT DISTINCT t1.n, vw dtp.n 

FROM t1, (SELECT DISTINCT t2.t1 id, t2.n 
FROM t2) vw dtp 

WHERE t1.id = vw dtp.t1 id 


6.3.9 非 重复 消除 


从 10.2.0.4 版 本 开始 可 用 的 非 重 复 消 除 (Distinct Elimination ) 的 目的 ， 是 移 除 对 于 保证 结果 集 不 
包含 重复 数据 来 说 不 需要 的 DISTINCT 运 算 符 。 这 是 一 种 基于 启发 式 的 查询 转换 ， 可 以 在 SELECT 子 句 涉 
及 以 下 情况 时 使 用 , 在 不 修改 要 查询 的 列 的 情况 下 , 查询 所 有 的 主键 列 、 所 有 非 空 的 唯一 键 列 或 rowid。 

下 面 的 例子 来 自 distinct elimination.sql 脚 本 。 注 意 ， 表 的 主键 定义 在 名 为 id 的 列 上 : 


SELECT DISTINCT id, n 
FROM 七 


由 于 id 列 的 出 现 ， 也 就 是 表 的 主键 ， 在 SELECT 子 句 中 就 足以 保证 数据 行 的 唯一 性 。 于 是 ， 非 重复 
消除 产生 了 以 下 查询 : | 


SELECT jds nh 
FROM 七 


6.3.10 ”Group-by 放置 


Group-by 放 置 ( Group-by Placement ) 的 目的 基本 上 与 非 重复 放置 一 样 。 唯 一 明显 的 差别 是 它们 应 
用 的 查询 类 型 不 同 。 前 者 适用 于 包含 GROUP BY 子 句 的 查询 ， 后 者 适用 于 包含 DISTINCT 运 算 符 的 查询 。 
Group-by 放 置 是 基于 成 本 的 查询 转换 ， 从 11.1 版 本 开始 起 才 可 用 。 

在 下 面 这 个 来 自 group_by_placement.sql 脚 本 的 例子 中 , 在 两 张 表 中 存在 父 - 子 关系 , 且 子 表 (t2 ) 
包含 的 记录 数 比 父 表 (td ) 更 多 : 


SELECT t1.n, t2.n, count(*) 
FROM t1, t2 

WHERE t1.id = t2.t1 id 
GROUP BY ti.n, t2.n 


当 t2.n 中 不 同 值 的 数量 远 远 小 于 子 表 中 存储 的 数据 行 的 数量 时 ，group-by 放 置 就 产生 了 下 面 的 查 
询 。 一 个 额外 的 GROUP BY 子 句 被 应 用 于 子 表 的 数据 上 ， 以 便 在 连接 父 表 之 前 消除 重复 。 还 要 注意 , 在 
顶层 查询 的 SELECT 子 句 中 ，count 函 数 被 sum 函 数 蔡 换 了 : 


SELECT t1.n, vw gb.n, sum(vw gb.cnt) 

FROM t1, (SELECT t2.t1 id, t2.n, count(*) AS cnt 
FROM t2 
GROUP BY t2.t1 id, t2.n) vw gb 

WHERE t1.id = vw gb.t1 id 

GROUP BY t1.n, vw gb.n 
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6.3.11 _ Order-By 消除 


Order-By 消 除 ( Order-By Elimination ) 的 目的 是 从 子 查询 、 内 联 视图 以 及 常规 视图 中 移 除 不 必要 
的 ORDER BY 子 句 。 很 显然 这 种 基于 启发 式 的 查询 转换 不 会 考虑 顶层 SELECT 子 句 。 当 一 个 ORDER BY 后 面 
跟随 一 个 不 保证 会 按 顺 序 返回 数据 的 操作 时 ， 或 者 跟随 一 个 会 按照 不 同 顺序 返回 数据 的 操作 时 ， 就 可 
以 认为 这 个 ORDER BY 子 句 是 没有 必要 的 ; 例如 ， 后 面 跟随 另 一 个 ORDER BY 或 者 聚合 。 

在 下 面 这 个 来 自 order_by_elimination.sql 脚 本 的 例子 中 , 不 仅 内 联 视图 中 有 一 个 ORDER BY， 而 且 
顶层 查询 块 中 还 有 一 个 GROUP BY: 

SELECT n2, count(*) 

FROM (SELECT n1，n2 

FROM 二 


ORDER BY n1) 
GROUP BY n2 


因为 顶层 查询 块 中 的 GROUP BY 并 不 保证 按 顺 序 返 回 数据 ， 所 以 order-by 消 除 就 会 移 除 ORDER BY 并 产 
生 以 下 查询 : 

SELECT n2, count(*) 

FROM (SELECT ni1, n2 


FROM t) 
GROUP BY n2 


查询 优化 器 使 用 选择 列表 裁剪 和 简单 视图 合并 进一步 将 查询 转化 成 以 下 形式 : 


SELECT n2, count(*) 
FROM 二 
GROUP BY n2 


6.3.12” 子 查询 展开 


子 查询 展开 ( Subquery Unnesting ) 的 目的 是 将 半 连 接 ( IN, EXISTS )、 反 连接 ( NOT IN, NOT EXISTS ) 
以 及 标量 子 查 询 注 入 到 查询 块 包含 的 FROM 子 句 中 去 ， 并 将 它们 转化 为 内 联 视 图 。 一 些 展开 是 由 基于 启 
发 式 的 查询 转换 执行 的 ， 另 外 一 些 则 是 由 基于 成 本 的 查询 转换 实施 的 。 应 用 这 种 查询 转换 的 主要 原因 
是 启用 所 有 可 能 的 连接 方法 。 事 实 上 ， 如 果 没 有 子 查 询 展 开 ， 子 查询 可 能 就 不 得 不 在 包含 它 的 查询 块 
每 返回 一 行 数 据 时 都 执行 一 遍 ( 详 见 第 10 章 )。 然 而 子 查询 展开 也 并 非 总 能 执行 。 例 如 ， 如 果子 查询 
中 包含 某 种 类 型 的 聚合 或 者 包含 rownum 伪 列 ， 展 开 都 不 可 能 执行 。 当 半 连 接 和 反 连 接 子 查询 中 含有 集 
合 运 算 符 时 , 只 有 从 11.2 版 本 开始 才 可 以 展开 。 此 外 , 从 12.1 版 本 开始 , 标量 子 查询 展开 改进 为 在 SELECT 
子 句 中 处 理 标 量子 查询 。 

下 面 的 例子 来 自 subquery_unnesting.sql 脚 本 ， 演 示 了 这 种 查询 转换 是 如 何 工 作 的 : 

SELECT ~ 

FROM t1 

WHERE EXISTS (SELECT 1 

FROM t2 


WHERE t2.id = t1.id 
AND t2.pad IS NOT NULL) 
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子 查 询 展开 可 以 归纳 为 两 个 步骤 。 第 一 步 ， 如 下 面 的 查询 所 示 ， 重 写 子 查询 为 内 联 视 图 。 注 意 ， 
下 面 展 示 的 并 不 是 合法 的 SQL 语句 , 因为 实现 半 连 接 的 运算 符 ( s= ) 在 SQL 语法 中 并 不 可 用 ( 只 在 SQL 
引擎 内 部 使 用 ): 
SELECT * 
FROM t1, (SELECT id 
FROM t2 


WHERE pad IS NOT NULL) sq 
WHERE t1.id s= sq.id 


第 二 步 ， 正 如 此 处 展示 的 ， 将 内 联 视 图 重 写 为 正常 的 连接 : 


SELECT t1.* 
FROM t1, t2 
WHERE t1.id s= t2.id AND t2.pad IS NOT NULL 


尽管 前 面 的 例子 是 基于 半 连 接 的 ， 这 个 查询 转换 同样 适用 于 反 连 接 。 唯 一 的 区 别 是 使 用 反 连 接 运 
算 符 (a= )， 而 不 是 半 连 接 运算 符 〈s= )。 这 是 另外 一 个 SQL 引擎 仅 在 内 部 使 用 的 运算 符 。 人 


6.3.13” 子 查询 合并 


子 查询 合并 ( Subquery Coalescing ) 的 目的 是 将 等 价 的 半 连 接 以 及 反 连 接 子 查询 组 合 到 同一 个 查 
询 块 中 。 应 用 这 种 自 11.2 版 本 起 可 用 的 基于 启发 式 的 查询 变换 ， 其 主要 目的 是 减少 表 访 问 的 数量 ， 从 


而 减少 连接 的 数量 。 
下 面 的 例子 来 自 subquery_coalescing.sql 肢 本， 演示 了 这 种 查询 转换 是 如 何 工作 的 。 注 意 ， 两 个 
相互 关联 的 子 查 询 处 理 相 同 的 数据 ， 只 是 限制 条 件 有 所 区 别 : 


SELEGT 六 
FROM t1 
WHERE EXISTS (SELECT 1 
FROM t2 
WHERE t2.id = t1.id AND t2.n > 10) 
OR EXISTS (SELECT 1 
FROM 七 2 
WHERE t2.id = t1.id AND t2.n < 100) 


子 查询 合并 组 合 两 个 子 查询 并 产生 以 下 查询 : 


SELEGT = 
FROM t1 
WHERE EXISTS (SELECT 1 
FROM t2 
WHERE t2.id = t1.id AND (t2.n > 10 OR t2.n < 100)) 


通过 子 查询 展开 ， 可 以 将 查询 进一步 转化 成 以 下 形式 。 注 意 ， 正 如 在 上 一 节 中 所 解释 的 ， 下 面 的 
查询 使 用 一 个 特殊 的 运算 符 (s= ) 来 实现 半 连 接 。 这 个 运算 符 仅 可 以 在 SQL 引擎 内 部 使 用 ， 并 非 那 种 
可 以 在 书写 SQL 语句 时 指定 的 语法 的 一 部 分 : 

SELECT t1.* 


FROM t1, t2 
WHERE t1.id s= t2.id AND (t2.n > 10 OR t2.n < 100) 
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6.3.14 ”使 用 窗口 函数 移 除 子 查询 


使 用 窗口 函数 移 除 子 查询 ( Subquery Removal Using Window Function ) 的 目的 是 使 用 窗口 函数 替 
换 包含 聚合 函数 的 子 查询 。 这 是 一 种 基于 启发 式 的 查询 转换 ,可 以 在 一 个 查询 块 包含 所 有 出 现在 一 个 
子 查询 中 的 表 和 谓词 时 应 用 。 

下 面 的 例子 基于 subquery_removal.sql 脚 本 ,演示 了 这 种 查询 转换 是 如 何 工作 的 。 注 意 ， 在 顶层 
查询 和 子 查询 中 都 引用 了 t2 表 : 


SELECT thaids tlmns 让 
FROM t1, t2 
WHERE t1.id = t2.t1 id 
AND t2.n = (SELECT max(n) 
FROM t2 
WHERE t2.t1 id = t1.id) 


查询 转换 移 除 子 查 询 ， 并 产生 接 下 来 的 查询 。 注 意 CASE 表 达 式 是 如 何 用 来 生成 某 种 标志 的 。 这 种 
标志 用 来 识别 那些 满足 在 原始 查询 中 由 子 查询 指定 的 限制 条 件 的 记录 : 


SELECT Et1 id, ti nm; t2 ids t2'n 
FROM (SELECT t1.id AS t1 id, ti.n AS tl n, t2.id AS t2 id，t2.n AS t2 n, 
CASE t2.n 
WHEN max(t2.n) OVER (PARTITION BY t2.t1 id) THEN 1 
END AS max 
FROM t2, t1 
WHERE t1.id = t2.t1 id) vw wif 
WHERE max IS NOT NULL 


6.3.15 ”联接 消除 


联接 消除 (Join Elimination ) 的 目的 是 移 除 元 余 的 联接 ， 换 句 话 说， 是 为 了 在 即使 SQL 语句 明确 
要 求 的 情况 下 也 能 够 避免 执行 联接 。 对 于 查询 优化 器 来 讲 ,决定 实现 这 种 查询 转换 是 否 合理 的 关键 信 
息 ， 是 外 键 的 可 用 性 是 强制 的 还 是 被 标记 为 RELY 的 。 此 外 ， 从 11.2 版 本 开始 ， 还 会 将 基于 主键 的 自 联 
接纳 入 考虑 范围 之 内 。 这 种 基于 启发 式 的 查询 转换 在 使 用 包含 联接 的 视图 时 尤其 有 用 。 注 意 ， 无 论 如 
何 ， 联 接 消 除 也 可 以 应 用 于 没有 视图 的 SQL 语句 。 

来 看 下 面 这 个 基于 join_elimination.sql 脚 本 的 例子 。 下面 的 SQL 语 句 定义 了 一 个 视图 。 注意 , 在 
这 两 张 表 之 间 存 在 着 父 - 子 关系 。 实 际 上 是 t2 表 用 它 的 t1_id 列 引用 了 ti1 表 的 主键 : 


CREATE VIEW v AS 
SELECT t1.id AS tl id, ti.n AS tl ny t2.id AS t2 id, t2.n AS t2_n 


FROM t1, t2 

WHERE t1.id = t2.t1 id 

当 执 行 简单 的 SELECT * FROM Vv 语句 时 ， 可 以 执行 简单 视图 合并 ， 然 后 这 个 查询 就 会 转化 如 下 : 
SELECT t1.id AS t1 id, ti.n AS tl n, t2.id AS t2 id, t2.n AS t2_n 

FROM t1, t2 


WHERE t1.id = t2.t1 id 
但 是 ， 如 下 一 个 例子 所 演示 的 ， 仅 当 引 用 在 子 表 中 定义 的 列 时 ( 例如，SELECT t2_id, t2_n FROM 
v), 查询 优化 器 才能 消除 与 父 表 的 联接 。 这 种 转换 能 够 实现 是 因为 ， 外 键 约束 保证 t2 表 中 所 有 的 记录 
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一 定 引 用 t1 表 中 的 一 条 记录 且 只 引用 一 条 : 


SELECT t2.id AS t2 id, t2.n AS t2_n 
FROM t2 


6.3.16 ”联接 因 式 分 解 


这 种 自 11.2 版 本 开始 可 用 的 联接 因 式 分 解 ( Join Factorization ) 的 目的 ， 是 识别 出 正在 处 理 的 联合 
查询 的 一 部 分 是 否 可 以 在 各 个 组 成 查询 中 共享 ， 进 而 避免 重复 的 数据 访问 和 联接 。 实 际 上 ,没有 这 种 
查询 转换 ， 所 有 的 组 件 查询 在 应 用 集合 运算 符 之 前 都 得 单独 执行 。 这 是 一 种 基于 成 本 的 查询 转换 ， 查 
询 优 化 器 只 有 在 基于 UNION ALL 集 合 运算 符 的 联合 查询 中 会 应 用 它 。 

下 面 的 例子 来 自 join_factorization.sql 脚 本 。 注 意 这 两 个 组 件 查 询 不 仅 是 访问 同一 张 表 ,它们 
还 都 在 相同 的 表 ( t2 ) 中 施加 了 一 个 限制 条 件 。 没 有 这 种 查询 转换 ， 两 个 组 件 查询 都 会 单独 执行 ， 两 
个 查询 中 的 表 都 会 被 访问 两 次 : 

SELECT * 

FROM t1, t2 

WHERE t1.id = t2.id AND t2.id < 10 

UNION ALL 

SELECT * 


FROM t1, t2 出 
WHERE t1.id = t2.id AND t2.id > 990 


为 避免 重复 处 理 访问 每 张 表 两 次 的 工作 ， 联 接 因 式 分 解 可 以 转换 这 个 查询 ， 如 下 面 的 例子 所 示 。 
因为 表 t1 被 因 式 分 解 了 ， 所 以 它 只 需 访问 一 次 。 根 据 表 的 大 小 以 及 所 选择 的 用 于 从 中 抽取 数据 的 访问 
路 径 的 不 同 ， 在 IO 和 CPU 使 用 方面 节省 的 成 本 可 能 会 非常 显著 : 


SELECN 本 
FROM t1，(SELECT * 

FROM t2 

WHERE id «< 10 

UNION ALL 

SELEGH * 

FROM t2 

WHERE id > 990) vw jf 
WHERE t1.id = vw jf.id 


6.3.17 ”外 联接 转 内 联接 


外 联接 转 内 联接 ( Outer Join to Inner Join ) 的 目的 是 将 不 必要 的 外 联接 转化 为 内 联接 。 这 样 做 是 
因为 外 联接 可 能 会 阻止 查询 优化 器 选择 某 种 特定 的 联接 方法 或 联接 顺序 。 这 是 一 种 基于 启发 式 的 查询 
转换 。 

下 面 的 例子 基于 outer to_inner.sql 脚 本 ， 演 示 了 这 种 查询 转换 。 注 意 ， 限 制 条 件 (t2.id IS NOT 
NULL ) 与 外 联接 条 件 ( t1.id = t2.t1 id(+) ) 有 冲突 : 


SEELEGJ 全 
FROM t1, t2 
WHERE t1.id = t2.t1 id(+) AND t2.id IS NOT NULL 
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查询 转换 移 除 了 外 联接 运算 符 以 及 多 余 的 谓词 ， 并 产生 了 以 下 查询 : 


SELECT * 
FROM t1, t2 
WHERE t1.id = t2.t1 id 


6.3.18 完全 外 联接 


完全 外 联接 (Full Outer Join ) 是 一 种 基于 启发 式 的 查询 转换 ， 其 目的 是 将 完全 外 联接 转换 为 一 个 
使 用 UNION ALL 集 合 运 算 符 的 复合 查询 ， 从 而 组 合 由 外 联接 和 反 联接 返回 的 记录 。 此 外 ， 如 果 ON 子 句 
指定 的 谓词 引用 了 非 空 列 ， 并 且 列 上 定义 了 强制 的 或 标记 为 RELY 的 外 键 约 束 ， 查 询 转换 甚至 能 够 将 完 
全 外 联接 转换 成 一 个 会 在 运行 时 作为 左 外 联接 执行 的 查询 语句 。 


注意 尽管 完全 外 联接 的 语法 从 9.0 版 本 开始 就 可 用 ,但 是 在 11.1 版 本 之 前 SQL 引擎 没有 能 力 执行 原生 
的 完全 外 联接 。 因 此 ,会 将 包含 完全 外 联接 的 查询 转换 成 某 种 SQL 引擎 能 够 工作 的 变 体 。 自 11.1 
版 本 开始 ， 随 着 原生 完全 外 联接 的 引入 ， 这 种 情况 就 不 存在 了 。 


下 面 的 例子 来 自 full_outer join.sql 和 脚本 ,演示 了 这 种 查询 转换 是 如 何 工作 的 。 注 意 ， 这 个 查询 
在 FROM 子 句 中 使 用 了 FULL OUTER JOIN 语 法 : 


SELECT + 
FROM t1 FULL OUTER JOIN t2 ON t1.n = t2.n 


查询 转换 产生 了 下 面 的 查询 。 注 意 ， 在 内 联 视图 中 定义 的 两 个 联接 中 ， 只 有 第 一 个 是 外 联接 。 第 
二 个 联接 使 用 之 前 在 6.3.12 节 中 解释 的 特殊 运算 符 ( a= ) 来 实现 反 联接 : 


SELECT id1 AS id, n1 AS n, pad1 AS pad, id, t1 id, n, pad 
FROM (SELECT t1.id AS id1, ti.n AS ni, ti.pad AS pad1i, t2.id, t2.t1 id, t2.n, t2.pad 
FROM t1, t2 
WHERE t1i.n = t2.n(+) 
UNION ALL 
SELECT NULL, NULL, NULL, t2.id, t2.t1 id, t2.n, t2.pad 
FROM tn 2 
WHERE t1.n a= t2.n) vw foj 


6.3.19 ” 表 扩 张 


自 11.2 版 本 开始 ， 可 用 的 表 扩 张 (Table Expansion ) 的 目的 是 通过 利用 部 分 不 可 用 的 索引 尽 可 能 
多 地 利用 索引 扫描 。 最 关键 的 是 要 认识 到 ， 这 种 基于 成 本 的 查询 转换 只 有 满足 以 下 三 个 基本 条 件 才 会 
考虑 应 用 : 

口 涉及 了 一 个 分 区 表 ; 

口 这 张 分 区 表 有 部 分 分 区 不 可 用 的 本 地 索引 ， 或 者 从 12.1 开 始 ， 有 一 个 局 部 索引 ; 

口 要 进行 优化 的 SQL 语 句 不 得 不 同时 处 理 可 用 和 不 可 用 索引 分 区 所 覆盖 的 数据 。 

在 11.2 版 本 之 前 过 到 这 种 情况 时 ， 基 于 部 分 不 可 用 的 索引 的 索引 扫描 是 不 可 能 的 ， 所 以 整个 索引 
会 被 完全 忽略 掉 ， 从 而 不 得 不 使 用 全 表 扫 描 。 但 是 通过 表 扩 张 ， 当 可 用 的 索引 分 区 出 现时 ， 查 询 优 化 
器 能 够 利用 它们 ， 并 且 在 遇 到 不 可 用 索引 分 区 时 ， 会 回 退 到 全 分 区 扫描 。 
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在 下 面 这 个 来 自 table_expansion.sql 脚 本 的 例子 中 ,有 一 个 范围 分 区 表 , 该 表 将 2014 年 的 每 个 季 
度 作为 一 个 分 区 。 注 意 ， 它 建立 的 本 地 索引 是 不 可 用 的 。 稍 后 会 为 一 个 单独 的 表 分 区 建立 一 个 可 用 的 
索引 分 区 。 


CREATE TABLE t ( 
id NUMBER PRIMARY KEY， 
d DATE NOT NULL， 
n NUMBER NOT NULL， 
pad VARCHAR2(4000) NOT NULL 


) 

PARTITION BY RANGE (d) ( 
PARTITION t q1 2014 VALUES LESS THAN (to date('2014-04-01' 
PARTITION t q2 2014 VALUES LESS THAN (to date('2014-07-01' 
PARTITION t_q3_2014 VALUES LESS THAN (to date('2014-10-01" 
PARTITION t q4 2014 VALUES LESS THAN (to date('2015-01-01' 


和 


CREATE INDEX i ON t (n) LOCAL UNUSABLE; 


‘yyyy-mm-dd' )), 
‘yyyy-mm-dd' )), 
‘yyyy-mm-dd' )), 
‘yyyy-mm-dd' )) 


vv vv vv ~» 


ALTER INDEX i REBUILD PARTITION t q4 2014; 

在 11.2 版 本 之 前 , 优化 下 面 这 样 的 查询 时 ,会 完全 避 开 索引 扫描 。 即 使 限制 条 件 是 基于 索引 列 的 ， 
也 并 非 所 有 需要 的 索引 分 区 都 是 可 用 的 。 于 是 ， 即 使 有 可 用 索引 的 表 分 区 ， 也 不 会 执行 索引 扫描 。 

SELECT * 


FROM t 
WHERE n = 8 
自 11.2 版 本 开始 ， 为 了 能 够 利用 可 用 的 索引 分 区 ， 会 将 查询 转换 成 一 个 联合 查询 ， 其 中 一 个 组 件 
查询 访问 带 有 可 用 索引 的 分 区 ， 另 一 个 组 件 查询 访问 带 有 不 可 用 索引 的 分 区 。 注 意 这 种 转换 是 如 何 通 
过 向 两 个 组 件 查询 都 加 入 基于 分 区 键 的 谓词 来 实现 的 : 
SELECT * 
FROM (SELECT * 
FROM 证 
WHERE n = 8 
AND d < to date('2014-10-01','yyyy-mm-dd') 
UNION ALL 
SELECT * 
FROM +t 
WHERE n = 8 
AND d >= to date('2014-10-01','yyyy-mm-dd') 
AND d «< to date('2015-01-01','yyyy-mm-dd')) vw te 


6.3.20 ”集合 操作 联接 转变 


集合 操作 联接 转变 ( Set to Join Conversion ) 的 目的 是 在 涉及 INTERSECT 和 MINUS 的 联合 查询 中 避免 
排序 操作 。 这 种 查询 转换 还 为 这 样 的 查询 将 消除 重复 推迟 到 处 理工 作 的 最 后 。 

基于 INTERSECT 和 MINUS 集 合 运算 符 的 联合 查询 基本 上 按 以 下 两 个 步骤 执行 。 

(1) 每 个 组 件 查询 独立 执行 ， 然 后 将 结果 集 排 序 ， 并 消除 重复 记录 。 

(2) 接 下 来 执行 集合 运算 符 ， 然 后 最 终结 果 集 就 确定 了 。 
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这 种 涉及 INTERSECT 或 MINUS 运 算 的 查询 方式 并 非 总 是 高 效 的 。 举 例 来 说 ， 当 组 件 查询 返回 大 量 数 
据 , 但 这 些 数据 中 的 大 部 分 被 集合 运算 符 所 消除 时 ， 大 部 分 后 来 被 消除 的 数据 最 后 都 进行 了 不 必要 的 
排序 。 通 过 将 查询 转换 为 一 种 允许 在 排序 之 前 就 丢弃 元 余数 据 的 方式 ， 集 合 操 作 联 接 转变 可 以 避免 这 
种 低 效 运算 。 此 外 ， 因 为 集合 运算 符 被 联接 取代 了 ， 也 启用 了 额外 的 访问 路 径 。 这 是 一 种 基于 启发 式 
的 的 查询 转换 ， 默 认 情况 下 并 未 启用 "。 为 了 利用 这 种 转换 必须 使 用 hint set to join。 

下 面 的 例子 来 自 set_to_join.sql 脚 本 。 这 个 联合 查询 基于 INTERSECT 集 合 运算 符 : 


SELECT * 

FROM t1 

WHERE n > 500 
INTERSECT 

SELECT * 

FROM t2 

WHERE t2.pad LIKE ‘A%' 


查询 转换 将 集合 运算 符 转 化 成 了 一 个 联接 。 此 外 ， 为 确保 仅 返 回 需 要 的 记录 ， 查 询 转 换 还 添加 了 
几 个 谓词 和 一 个 DISTINCT 运 算 符 。 下 面 是 集合 操作 联接 转变 完成 以 后 最 终 的 查询 语句 : 


SELECT DISTINCT t1.* 

FROM t1，t2 

WHERE t1,id = t2.id AND tl1.n = t2.n AND t1.pad = t2.pad 
AND t1.n > 500 AND t1.pad LIKE “A%” 

AND t2.n > 500 AND t2.pad LIKE “A% 


6.3.21 星 型 转换 


星 型 转换 ( Star Transformation ) 是 一 种 基于 成 本 的 查询 转换 , 用 于 从 星 型 模型 中 提取 数据 的 查询 。 
第 14 章 将 介绍 关于 星 型 模型 和 针对 这 种 模型 的 查询 优化 的 详细 信息 。 


6.3.22 ”物化 视图 查询 重 写 


物化 视图 查询 重 写 ( Query Rewrite with Materialized View ) 是 一 种 优化 技术 。 该 技术 允许 数据 库 
引擎 在 即使 待 优化 的 查询 并 未 直接 引用 物化 视图 的 情况 下 ， 也 能 访问 在 物化 视图 中 存储 的 数据 。 第 15 
章 详细 讨论 了 这 种 类 型 的 查询 转换 。 


6.4 小结 


本 章 描述 了 关于 查询 优化 器 的 基础 知识 。 你 已 经 了 解 了 查询 优化 器 用 于 生成 执行 计划 的 输入 项 的 
内 容 ， 也 学 习 了 构成 SQL 引擎 的 关键 组 件 以 及 它们 彼此 之 间 是 如 何 相互 作用 的 ， 同 时 学 习 了 关于 查询 
转换 的 内 容 ， 以 及 如 何 应 用 它们 来 增加 为 某 个 给 定 SQL 语 名 找寻 更 好 执行 计划 的 机 会 。 

系统 统计 信息 是 本 章 介绍 的 输入 项 中 的 一 种 。 它 们 的 用 途 是 描述 运行 数据 库 引擎 的 系统 以 及 存储 
子 系统 在 运行 时 的 表现 。 第 7 章 将 详细 描述 什么 是 系统 统计 信息 ， 如 何 管理 它们 ， 以 及 查询 优化 器 如 
何 利 用 它们 增强 估算 能 力 。 


中 初始 化 参数 _convert_set to join 默认 设置 为 FALSE。 


系统 统计 信息 


查询 优化 器 曾 基 于 执行 SQL 语句 需要 的 物理 读 的 数量 进行 成 本 估算 。 这 一 方法 称 为 JO 成 本 模型 。 
该 方法 的 主要 缺陷 是 ， 单 块 物 理 读 和 多 块 物理 读 在 成 本 上 是 等 价 的 "。 结 果 ， 类 似 全 表 扫 描 这 样 的 多 
块 读 操 作 受 到 了 青睐 。 在 引入 系统 统计 信息 之 前 ， 尤 其 是 在 OLTP 系 统 上 ，optimizer index_caching 
和 optimizer_index_cost_adj 这 两 个 初始 化 参数 曾 用 于 解决 这 个 问题 ( 详 见 第 9 章 )。 事实 上 ， 这 两 个 
参数 的 默认 值 过 去 只 适合 报表 系统 和 数据 仓库 。 如 今 ， 一 种 新 的 成 本 计算 方法 ， 即 CPU 成 本 模型 ， 用 
于 纠正 这 一 缺陷 。 要 使 用 CPU 成 本 模型 ， 必 须 将 系统 统计 信息 〈《 即 ， 关 于 数据 库 引擎 运行 所 在 系统 的 
性 能 的 额外 信息 ) 提供 给 查询 优化 器 。 从 本 质 上 讲 ， 系 统统 计 信息 提供 以 下 信息 : 

口 磁盘 1/O 子 系统 的 性 能 

口 CPU 的 性 能 

尽管 其 名 称 如 此 ,CPU 成 本 模型 同样 考虑 到 了 物理 读 ,而 且 也 考虑 到 了 磁盘 1/0 子 系统 的 性 能 表现 ， 
而 不 是 仅仅 把 WO 成 本 建立 在 物理 读数 值 的 基础 上 。 不 要 让 名 称 误导 你 。 

通常 总 是 有 一 组 默认 的 系统 统计 信息 可 供 使 用 。 因 此 ， 默 认 情 况 下 CPU 成 本 模型 是 启用 的 。 实 际 
上 ， 使 用 MO 成 本 模型 的 唯一 途径 是 在 SQL 语句 级 别 指定 no_cpu_costing 这 个 hint， 或 者 设置 一 个 未 公 
开 的 初始 化 参数 。 在 其 他 所 有 情况 下 ， 查 询 优化 器 都 使 用 CPU 成 本 模型 。 


7.1 dbms stats 包 


dbms_stats 包 提供 一 组 全 面 的 存储 过 程 来 管理 系统 统计 信息 。 默 认 情 况 下 ， 这 个 包 直 接 修 改 数据 
字典 ,尽管 如 此 , 包 中 大 部 分 存储 过 程 都 可 以 使 用 一 张 存储 在 数据 字典 之 外 的 用 户 自 定义 表 进 行 运转 。 
这 张 表 就 是 我 所 说 的 备份 表 。 该 表 主 要 用 于 以 下 两 种 情形 。 

口 在 不 必 将 统计 信息 存储 在 数据 字典 中 的 情况 下 收集 系统 统计 信息 ， 因 此 也 就 无 需 在 收集 完毕 

后 使 它们 立即 对 查询 优化 器 可 见 。 

口 为 了 在 两 个 数据 库 之 间 移 动 系统 统计 信息 。 

在 两 个 数据 库 之 间 移 动 系 统统 计 信息 就 是 ， 将 系统 统计 信息 导出 到 源 端 数据 库 的 一 张 备 份 表 中 ， 
将 这 张 备份 表 移 动 到 男 一 个 数据 库 , 然后 将 表 中 的 内 容 导 入 到 目标 数据 字典 中 。 在 数据 库 之 间 移 动 系 
统统 计 信息 是 一 种 确保 所 有 与 某 一 给 定 的 应 用 程序 ( 例如 ， 开 发 、 测 试 和 生产 环境 ) 有 关 的 数据 库 都 


中 一 般 来 说 , 读 单个 块 比 读 多 个 快要 快 些 。 但 说 来 奇怪 ,在 现实 中 并 非 总 是 这 样 的 。 在 任何 情况 下， 重要 的 是 ， 要 
记 住 这 两 者 之 间 确 实 有 所 区 别 。 
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使 用 相同 的 系统 统计 信息 方法 。 


注意 ”系统 统计 信息 的 收集 不 会 使 存储 在 库 缓存 中 的 游标 失效 。 因 此 ， 新 的 系统 统计 信息 只 会 作用 
于 即将 需要 进行 硬 解 析 的 SQL 语句 。 


dbms_stats 包 提供 以 下 子 程序 ( 见 图 7-1 ): 

口 gather_system_stats 收 集 系统 统计 信息 并 将 它们 存储 在 数据 字典 或 备份 表 中 ; 
口 delete_system_stats 删 除 存储 在 数据 字典 或 备份 表 中 的 系统 统计 信息 ; 

口 restore_system_stats 将 系统 统计 信息 还 原 到 数据 字典 中 ; 

口 export_system_stats 将 系统 统计 信息 从 数据 字典 移动 到 备份 表 中 ; 

口 import_system_stats 将 系统 统计 信息 从 备份 表 移动 到 数据 字典 中 ; 

口 get_system_stats 提 取 存储 在 数据 字典 或 备份 表 中 的 系统 统计 信息 ; 

口 set_system_stats 修 改 存储 在 数据 字典 或 备份 表 中 的 系统 统计 信息 。 


获取 
收集 /删除 /设置 


通过 数据 迁移 
工具 复制 三 , 获取 
收集 /删除 /设置 


图 7-1 dbms_stats 包 提供 一 组 全 面 的 存储 过 程 来 管理 系统 统计 信息 


默认 情况 下 , 执行 dbms_stats 包 的 权限 是 授予 public 的 。 这 就 意味 着 每 个 用 户 都 可 以 收集 系统 统计 
信息 。 尽管 如 此 ,只 有 那些 持 有 gather_ system statistics 角 色 所 提供 权限 的 用 户 才能 将 系统 统计 信息 存 
储 到 数据 字典 中 。 没 有 授权 的 用 户 只 能 将 它们 存储 到 备份 表 中 。 默 认 情 况 下 ,gather_system statistics 
角色 是 通过 dba 角 色 提 供 的 。 


7.2 ”有 哪些 系统 统计 信息 可 用 


有 两 种 类 型 的 系统 统计 信息 : 无 负载 统计 信息 和 工作 负载 统计 信息 。 这 两 种 统计 信息 的 主要 区 别 
就 是 用 于 测量 磁盘 IO 子 系统 的 的 方法 不 同 。 前 者 运行 复合 基准 测试 ,而 后 者 使 用 应 用 基准 测试 。 两 种 
情况 下 CPU 的 性 能 都 是 通过 复合 基准 测试 计算 的 。 在 深入 讨论 这 两 种 方法 的 区 别 之 前 ， 我 们 先 来 看 看 
系统 统计 信息 在 数据 字典 中 是 如 何 存储 的 。 
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应 用 基准 测试 与 复合 基准 测试 
应 用 基准 测试 ， 也 称 为 真实 基准 测试 ， 它 基于 真实 应 用 程序 的 日 常 操 作 产生 的 负载 。 尽 管 它 通 
常 可 以 非常 精确 地 提供 关于 运行 应 用 的 系统 的 真实 性 能 数据 ,但 由 于 其 本 身 的 特性 ， 以 可 控 的 方式 
应 用 它 并 非 总 是 可 行 的 。 
复合 基准 测试 是 由 不 执行 真实 工作 的 程序 所 产生 的 工作 负载 。 总 体 思 路 是 它 应 该 通过 执行 类 似 
的 操作 模拟 应 用 程序 的 负载 。 尽 管 这 种 方法 可 以 很 容易 通过 可 控 的 方式 进行 应 用 , 但 是 通常 它 不 会 
产生 与 应 用 基准 测试 一 样 精确 的 性 能 指标 。 虽 然 如 此 ， 它 在 对 比 不 同系 统 方 面 仍 非 常 有 用 。 
村 
系统 统计 信息 存储 在 字典 表 aux_stats$° 中 。 然而 , 没有 一 个 数据 字典 视图 能 够 使 其 具体 化 。 在 这 
张 表 中 ， 由 下 面 三 组 通过 sname 列 的 不 同 值 来 区 分 的 数据 集合 来 记录 。 
口 值 为 SYSSTATS_INF0 的 记录 是 包含 系统 统计 信息 状态 以 及 对 应 收集 时 间 的 数据 集合 。 如 果 正 确 
收集 了 这 些 信息 ， 则 会 将 STATUS 列 设置 为 COMPLETED。 如 果 在 收集 统计 信息 过 程 中 出 现 了 问题 ， 
则 会 将 STATUS 列 设置 为 BADSTATS， 也 就 是 说 查询 优化 器 不 会 使 用 系统 统计 信息 。 在 收集 工作 负 
载 统计 信息 时 可 能 还 会 看 见 另外 两 个 值 : MANUALGATHERING 和 AUTOGATHERING。 名 为 FLAGS 的 属性 
接受 以 下 三 个 值 : 0 代表 系统 统计 信息 通过 调用 delete_system_stats 存 储 过 程 设 置 为 默认 值 ; 
1 代表 系统 统计 信息 是 正常 收集 或 设置 的 ; 128 表 示 系 统统 计 信 息 通过 调用 restore_system_ 
stats 存 储 过 程 进行 还 原 。 


SQL> SELECT pname，pval1，pval2 
2 FROM sys.aux stats$ 
3 WHERE sname = "SYSSTATS INFO'; 


PNAME PVAL1 PVAL2 


DSTART 10-25-2013 23:26 
DSTOP 10-25-2013 23328 
FLAGS 1 

STATUS COMPLETED 


口 值 为 SYSSTATS_MAIN 的 记录 是 包含 系统 统计 信息 本 身 的 数据 集合 。 详 细 信息 会 在 下 节 中 介绍 。 


SQL> SELECT pname，pval1 
2 FROM sys.aux stats$ 
3 WHERE sname = "SYSSTATS MAIN'; 


PNAME PVAL1 
CPUSPEEDNW 1991.0 
IOSEEKTIM 10.0 
IOTFRSPEED 4096.0 
SREADTIM 1.6 
MREADTIM 7ag 
CPUSPEED 1992.0 
MBRC 21.0 
MAXTHR 659158016.0 
SLAVETHR 34201600.0 


中 如 果 无 法 直接 访问 字典 表 awx_stats$， 可 转 而 使 用 get_system_stats 程 序 
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口 值 为 SYSSTATS_TEMP 的 记录 是 包含 用 于 计算 系统 统计 信息 的 值 的 数据 集合 。 只 在 收集 工作 负载 
统计 信息 时 可 见 。 


7.3 ”收集 系统 统计 信息 


正如 刚刚 所 描述 的 ， 数 据 库 引擎 支持 两 种 类 型 的 系统 统计 信息 : 无 负载 统计 信息 和 工作 负载 统计 
信息 。 本 节 不 仅 会 介绍 它们 是 如 何 收集 的 ， 而 且 还 会 说 明 它们 向 查询 优化 器 提供 什么 样 的 信息 ， 并 会 
说 明 如 何 决定 应 该 采用 无 负载 统计 信息 还 是 工作 负载 统计 信息 。 

因为 对 于 单个 数据 库 来 讲 只 存在 一 组 单独 的 统计 信息 ， 所 以 RAC 系 统 中 的 所 有 实例 都 使 用 相同 
的 系统 统计 人 信息。 因此， 如果 各 个 节点 大 小 或 负载 不 均衡 ， 就 必须 仔细 判断 应 该 收集 哪个 节点 的 系 
统统 计 信息 。 


7.3.1 无 工作 负载 统计 信息 


无 工作 负载 统计 信息 总 是 可 用 的 。 如 果 显 式 删除 它们 , 那么 它们 会 在 数据 库 下 次 启动 过 程 中 自动 
收集 。 因 为 数据 库 引 擎 采用 了 复合 基准 来 产生 用 于 测量 系统 性 能 的 负载 ， 所 以 可 以 在 空闲 的 系统 上 收 
集 无 工作 负载 统计 信息 。 为 了 测量 CPU 的 速度 ， 很 可 能 会 循环 执行 某 种 标准 化 的 操作 。 为 了 测量 磁盘 
IO 性 能 ， 会 在 数据 库 的 几 个 数据 文件 上 执行 一 些 不 同 大 小 的 读 操 作 。 

要 收集 无 工作 负载 统计 信息 ， 需 要 将 gather_system stats 存 储 过 程 的 gathering_mode 参 数 设置 为 
noworkload， 如 下 例 所 示 : 


dbms_stats.gather system stats(gathering mode => "noworkload ' ) 


此 外 , 为 了 更 好 地 支持 拥有 更 高 磁盘 IO 吞吐 量 的 系统 ( 例如 Exadata )， 从 11.2.0.4 版 本 ( 或 者 是 安 
装 了 与 bug 0248538 相 关 的 增强 的 补丁 ) 开始 有 了 另外 一 种 收集 无 工作 负载 统计 信息 的 方法 : 将 
gathering_mode 参 数 的 值 设 置 为 exadata， 如 下 所 示 : 


dbms_stats.gather system stats(gathering mode => 'exadata') 


这 两 种 情况 下 ， 收 集 过 程 通常 持续 几 分 钟 ， 然 后 就 会 计算 出 表 7-1 所 列举 的 统计 信息 。 奇 怪 的 是 ， 
有 时 候 需 要 重复 收集 统计 信息 的 过 程 ; 否则 , 就 会 使 用 表 7-1 中 的 默认 值 。 这 是 因为 测量 出 来 的 统计 信 
息 在 存储 之 前 必须 通过 合理 性 检查 。 如 果 它 们 通 不 过 合理 性 检查 ， 就 会 被 丢弃 并 被 默认 的 统计 信息 替 
换 掉 。 然 而 ， 进 行 这 些 检查 时 没有 可 以 提供 给 你 的 信息 。 


表 7-1 存储 在 数据 词典 中 的 无 工作 负载 统计 信息 
名 称 描 述 


CPUSPEEDW ”CPU 每 秒 钟 能 够 处 理 的 操作 数量 (单位 为 百 万 次 )。 因 为 CPUSPEEDM 总 是 基于 用 来 评估 CPU 速度 的 复合 
基准 的 结果 ， 所 以 没有 默认 值 


TOSEEKTIM 定位 磁盘 数据 所 需 平均 时 间 (单位 为 毫秒 ， 平 均 寻 道 时 间 )。 默 认 值 是 10 
IOTFRSPEED 每 毫秒 能 够 从 磁盘 传输 的 平均 字 节 数 。 默 认 值 是 4096 


MBRC 多 块 读 操作 每 次 读 的 块 的 数量 。 该 统计 信息 只 能 在 exadata 模 式 下 设置 ( 即 ， 将 gathering_mode 设 置 为 
exadata)。MBRC 没 有 默认 值 ， 因 为 它 总 是 与 db_ 人 i]e_multiblock_read_count 初 始 化 参数 一 致 


普通 无 工作 负载 统计 信息 与 exadata 无 工作 负载 统计 信息 的 唯一 区 别 就 是 后 者 的 mbrc 统 计 信息 也 
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被 设置 了 。 更 确切 地 说 ， 它 被 设置 成 db file _ multiblock read _ count 初始 化 参数 的 取 值 。 其 目的 是 告 
知 查询 优化 器 数据 库 引擎 能 够 高 效 地 执行 大 型 的 磁盘 IO 操作 , 因此 可 以 降低 全 表 扫 描 的 成 本 。 只 有 在 
db file multiblock read_count 初 始 化 参数 没有 明确 设置 的 情况 下 才 有 必要 使 用 exadata 收 集 模 式 。 没 
有 设置 这 个 参数 时 ， 查 询 优 化 器 会 使 用 8 这 个 值 来 计算 全 表 扫 描 的 成 本 ( 详 见 第 9 章 )。 使 用 这 样 的 值 ， 
全 表 扫 描 的 成 本 通常 会 比 预期 成 本 要 高 出 许多 。 使 用 exadata 模 式 时 ， 情 况 就 完全 不 一 样 了 。 实 际 上 ， 
大 多 数 系统 上 都 会 将 mbrc 设 置 为 128， 因 此 全 表 扫 描 的 成 本 要 低 出 许多 。 在 拥有 很 高 的 磁盘 IO 吞吐 量 
的 系统 ( 例如 Exadata ) 上 使 用 exadata 模 式 尤 为 明智 。 


7.3.2 工作 负载 统计 信息 


只 有 进行 了 明确 的 收集 操作 ， 工 作 负 载 统计 信息 方才 可 用 。 你 不 能 使 用 一 个 空闲 的 系统 来 收集 它 
们 , 因为 数据 库 引 擎 需要 利用 日 常数 据 库 负载 来 衡量 磁盘 IO 子 系统 的 性 能 。 另 一 方面 , 用 于 无 负载 统 
计 信 息 的 方法 可 用 来 衡量 CPU 的 速度 。 如 图 7-2 所 示 ， 收 集 工 作 负 载 统计 信息 是 一 个 三 步 操作 的 活动 。 
收集 的 思路 是 要 计算 一 个 操作 花费 的 平均 时 间 ， 因 此 ， 有 必要 知道 这 个 操作 执行 过 多 少 次 ， 以 及 有 多 
少时 间 花 费 在 执行 这 个 操作 上 面 。 例 如 ， 使 用 下 面 的 SQL 语句 ， 我 能 够 计算 出 测试 数据 库 的 平均 单 块 
读 的 时 间 (6.2 毫秒 )， 这 与 dbms_stats 包 的 执行 方式 一 样 : 

SQL> SELECT sum(singleblkrds) AS count， sum(singleblkrdtim)*10 AS time ms 

2 FROM v$filestat; 


COUNT TIME MS 


22893 36760 


SQL> REMARK run a benchmark to generate some disk I/0 operations... 


SOL> SELECT sum(singleblkrds) AS count, sum(singleblkrdtim)*10 AS time ms 
2 FROM v$filestat; 


COUNT TIME MS 


54956 236430 


SQL> SELECT round((236430-36760)/(54956-22893),1) AS avg tim singleblkrd 
2 FROM dual; 


AVG_TIM SINGLEBLKRD 


: -2- 运行 基准 测试 加 


+ 一 一 ”| 时 间 


-1- 开始 快照 -3- 结束 快照 并 计算 
图 7-2 为 收集 (计算 ) 系统 统计 信息 ， 使 用 了 一 些 性 能 指标 的 两 个 快照 
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图 7-2 中 列举 的 步骤 如 下 。 

(1) 一 个 含有 若干 性 能 数据 的 快照 被 捕获 下 来 并 存储 在 aux_stats$ 数 据 字典 表 中 ( 对 于 这 些 数据 ， 
sname 列 的 值 被 设置 为 SYSSTATS TEMP )。 这 个 步骤 是 通过 将 gather system stats 存 储 过 程 的 
gathering_mode 参 数 设置 为 start 来 执行 的 ， 如 下 面 的 命令 所 示 : 

dbms_stats.gather system stats(gathering mode => 'start') 

(2) 数据 库 引 擎 并 不 控制 数据 库 的 负载 。 这 样 会 导致 在 下 一 次 捕获 快照 之 前 ， 必 须 等 待 足够 长 的 
时 间 才 能 涵盖 一 个 有 代表 性 的 负载 。 很 难 给 出 关于 等 待 时 间 的 通用 建议 , 但 是 一 般 情 况 下 至 少 应 该 等 
待 5~10 分 钟 。 

(3) 捕获 第 二 个 快照 。 这 一 步骤 是 通过 将 gather_system stats 存 储 过 程 的 gathering_ mode 参 数 设 置 
为 stop 来 实现 的 ， 如 下 面 的 命令 所 示 : 

dbms_stats.gather system stats(gathering mode => 'stop') 

(4) 基于 两 次 快照 的 性 能 统计 数据 ， 计 算 表 7-2 中 所 列 的 系统 统计 信息 。 如 果 其 中 的 一 个 磁盘 IO 统 
计 信 息 无 法 计算 ， 那 么 就 会 将 这 个 统计 信息 设置 为 NWLL。 如 果 工 作 负载 没有 使 用 单 块 读 、 多 快 读 或 者 
并 行 处 理 中 的 一 种 ， 那 么 可 能 会 出 现 无 法 计算 某 种 统计 信息 的 情况 。 例 如 ， 如 果 工 作 负载 没有 执行 任 
何 的 多 块 读 ， 则 会 将 mbrc 和 mreadtim 设 置 为 NULL。 


表 7-2 ”存储 在 数据 字典 中 的 工作 负载 统计 信息 


列 名 描 述 
CPUSPEED 一 个 CPU 每 秒 钟 能 够 处 理 的 操作 数量 (单位 为 百 万 次 ) 
SREADTIM 执行 一 个 单 块 读 操 作 所 需 的 平均 时 间 (单位 为 毫秒 ) 
MREADTIM 执行 一 个 多 块 读 操作 所 需 的 平均 时 间 (单位 为 毫秒 ) 
MBRC 多 块 读 操 作 过 程 中 读 取 的 平均 块 数量 
MAXTHR 整个 系统 的 最 大 磁盘 IO 吞吐 率 (以 字 节 每 秒 为 单位 ) 
SLAVETHR 一 个 单独 的 并 行 处 理子 进程 的 平均 磁盘 1/O 吞 吐 率 (以 字 节 每 秒 为 单位 ) 
为 避免 手工 捕获 结束 的 快照 ， 也 可 以 将 gather _ system_stats 存 储 过 程 的 参数 gathering mode 设 置 


为 interval。 使 用 此 参数 的 情况 下 ， 起 始 的 快照 会 立即 进行 捕获 ， 而 结束 的 快照 会 安排 在 第 二 个 名 为 
interval 的 参数 指定 的 分 钟 数 之 后 执行 捕获 。 下 面 的 命令 指定 收集 统计 信息 的 过 程 持续 10 分 钟 : 


dbms_stats.gather system stats(gathering mode => 'interval', 
interval => 10) 


注意 ， 上 面 的 命令 的 执行 并 不 会 花费 10 分 钟 。 它 只 是 捕获 起 始 的 快照 ， 并 安排 一 个 在 10 分 钟 后 捕 
获 结束 的 快照 的 任务 。 可 以 通过 查询 看 见 这 个 任务 ， 例 如 user_scheduler jobs 视图 。 


警告 ”因为 bug 9842771， 工 作 负 载 系统 统计 信息 ， 尤 其 是 sreadtim 和 mreadtim 的 值 ， 在 11.2.0.1 版 本 
和 11.2.0.2 版 本 中 是 有 缺陷 的 。 要 修复 这 个 问题 ， 你 可 以 安装 补丁 9842771。 如 果 无 法 安装 这 个 
补丁 ， 那 么 可 以 采用 的 解决 方案 是 ， 手 工 设置 sreadtim 和 mreadtim 的 值 ( 稍 后 的 代码 样 例 中 会 
介绍 如 何 设置 这 些 值 六 
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收集 工作 负载 统计 信息 的 主要 问题 是 选择 合适 的 收集 时 长 。 事 实 上 ， 大 多 数 的 系统 都 经 历 着 除了 
恒定 负载 以 外 的 各 种 各 样 的 负载 ， 因 此 ， 工 作 负 载 统计 信息 演变 为 除了 cpuspeed 以 外 ， 其 他 都 是 不 恒 
定 的 。 图 7-3 展 示 了 我 在 一 个 生产 系统 上 测量 的 工作 负载 统计 信息 的 演变 。 为 了 生成 这 些 图 表 ， 我 以 1 
小 时 为 间隔 、 持 续 4 天 来 收集 工作 负载 统计 信息 。 为 此 所 写 的 SQL 语 句 的 例子 请 参阅 
system stats history. sal 和 system stats history job.sql 脚 本 。 
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图 7-3 ”在 大 多 数 系统 上 ， 工 作 负 载 统计 信息 的 演变 表现 为 除了 恒定 之 外 的 各 种 形式 


要 避免 在 无 法 提供 有 代表 性 负载 的 时 间 段 内 收集 工作 负载 统计 信息 ， 在 我 看 来 只 有 两 种 途径 。 要 
么 通过 持续 几 天 的 时 间 来 收集 工作 负载 统计 信息 ， 要 么 基于 更 短 的 时 间 段 ( 例如 ，10 分 钟 ) 来 生成 图 
表 ， 以 获取 合理 的 值 ( 如 图 7-3 )。 我 通常 建议 使 用 后 面 的 方法 ， 因 为 当 工作 负载 在 同一 时 间 段 内 变换 
非常 频繁 的 时 候 , 通过 几 天 时 间 计 算出 来 的 结果 可 能 会 非常 具有 误导 性 。 另外 , 使 用 更 短 的 时 间 间 隔 ， 
你 也 可 以 在 相同 的 时 间 获 取 有 用 的 系统 性 能 的 视图 。 

使 用 基于 较 短 间隔 的 方法 收集 信息 的 另 一 个 好 处 是 , 它 迫 使 你 不 立刻 更 改 数据 字典 中 的 系统 统计 
信息 。 事 实 上 ， 当 收集 系统 统计 信息 时 ， 更 好 的 做 法 是 把 它们 收集 在 一 张 备份 表 中 并 检查 其 一 致 性 。 
然后 ， 如 果 这 些 统计 信息 没 问 题 ， 再 将 它们 导入 到 数据 字典 中 。 

举例 来 讲 ， 根 据 图 7-3， 我 建议 为 nbrc、mreadtim 和 sreadtim 使 用 平均 值 ， 为 maxthr 和 slavethr 使 
用 最 大 值 。 类 似 下 面 的 PL/SQL 代 码 块 可 能 会 用 于 手工 设置 工作 负载 统计 信息 。 注 意 在 使 用 
set_system_stats 存 储 过 程 设置 工作 负载 统计 信息 之 前 ,会 通过 使 用 delete_system_stats 存 储 过 程 删 
除 掉 旧 的 系统 统计 信息 : 
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BEGIN 
dbms_stats.delete system stats(); 
dbms stats.set system stats(pname => 'CPUSPEED', pvalue => 772); 
dbms_stats.set system stats(pname => 'SREADTIM', pvalue => 5.5); 
dbms stats.set system stats(pname => 'MREADTIM', pvalue => 19.4); 


dbms_stats.set system stats(pname => 'MBRC', pvalue => 53); 
dbms_stats.set system stats(pname => 'MAXTHR', pvalue => 1136136192); 
dbms_stats.set system stats(pname => 'SLAVETHR', pvalue => 16870400); 


END; 
当 出 现 一 天 或 一 周 中 的 不 同时 段 需要 不 同 的 工作 负载 统计 信息 集合 的 情况 时 , 手工 设置 系统 统计 
信息 的 方法 也 适用 。 不 过 ， 必 须 指 出 ， 我 从 没 遇 到 过 需要 一 组 以 上 工作 负载 统计 信息 的 情形 。 


7.3.3 在 无 工作 负载 统计 信息 和 工作 负载 统计 信息 之 间 进 行 选择 


在 两 种 可 用 的 系统 统计 信息 之 间 进 行 选 择 其 实 是 在 简单 性 和 可 控 性 之 间 进 行 选 择 。 如 果 简 单 性 是 
问题 关键 ,你 或 许 会 选择 无 工作 负载 统计 信息 。 这 是 因为 ， 正 如 在 之 前 的 章节 中 所 描述 的 ， 无 工作 负 
载 统计 信息 更 加 容易 收集 。 


注意 ”最 简单 的 方法 是 使 用 默认 统计 信息 ， 你 可 以 通过 调用 delete_system stats 来 实现 。 对 于 某 些 
数据 库 ， 这 些 默认 的 统计 信息 可 能 就 是 你 所 需要 的 全 部 。 


然而 ， 通 过 选择 使 用 无 工作 负载 统计 信息 的 简单 方法 ， 你 失去 了 对 以 下 两 个 具体 特性 的 控制 。 
口 当 使 用 无 工作 负载 统计 信息 时 , 初始 化 参数 db file multiblock read_ count 的 值 可 能 会 影响 由 
查询 优化 器 执行 的 估算 。 第 9 章 中 会 讲 到 ,这 是 不 理想 的 。 而 在 工作 负载 统计 信息 中 ， 这 个 参 
数 的 角色 被 统计 信息 mbrc 取 代 。 
口 只 有 使 用 工作 负载 统计 信息 , 凭借 maxthr 和 slavethr 统 计 信 息 , 你 才 可 以 控制 并 行 操作 的 成 本 . 
这 两 个 特性 只 有 在 使 用 工作 负载 统计 信息 时 才 可 用 。 基 于 这 个 原因 ,我 认为 工作 负载 统计 信息 优 
先 级 更 高 ， 并 且 通 常会 推荐 它们 。 你 收集 工作 负载 统计 信息 时 的 额外 投入 会 在 长 期 内 获得 回报 。 


7.4 还 原 系 统统 计 信 息 


每 当 通过 dbms_stats 包 更 改 了 系统 统计 信息 ， 都 会 将 当前 的 统计 信息 保存 到 另 一 张 数据 字典 表 
(wii$ optstat_aux_history )， 而 非 简 单 地 使 用 新 的 统计 信息 覆盖 旧 的 ， 这 张 表 保 留 着 所 有 在 保留 期 
内 出 现 的 变化 。 其 用 途 是 ， 万 一 新 的 统计 信息 导致 低 效率 的 执行 计划 ， 能 够 还 原 旧 的 统计 信息 。 

出 于 还 原 旧 统计 信息 的 目的 , doms_stats 包 提供 了 restore_system_stats 存 储 过 程 。 这 个 存储 过 程 
只 接受 一 个 单独 的 参数 : 用 于 指定 目标 时 间 的 一 个 timestamp 类 型 的 值 , 统计 信息 被 还 原 为 在 指定 时 间 
点 使 用 的 那些 值 。 例 如 ， 下 面 的 PL/SQL 代 码 块 会 将 系统 统计 信息 还 原 为 一 天 以 前 的 样子 : 


BEGIN 

dbms_stats.delete system stats(); 

dbms_stats.restore system stats(as of timestamp => systimestamp - INTERVAL '1' DAY); 
END; 
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警告 为 确保 能 够 精确 地 还 原 指定 的 时 间 点 所 使 用 的 系统 统计 信息 ， 你 必须 在 还 原 之 前 删除 当前 的 
系统 统计 信息 。 和 否则， 还 原 的 统计 信息 实际 上 是 与 当前 所 使 用 的 所 有 统计 信息 合并 的 结果 。 


系统 统计 信息 ( 对 象 统计 信息 也 一 样 ， 因 为 它们 是 由 相同 的 基础 功能 维护 的 ) 在 历史 表 中 保存 一 
段 由 保留 期 指定 的 时 间 间 隔 。 默 认 值 是 31 天 。 你 可 以 通过 调用 dbms_stats 包 中 的 get_stats_history_ 
retention 函 数 来 显示 当前 值 ， 如 下 所 示 : 

SELECT dbms stats.get stats history retention() AS retention FROM dual 


为 了 修改 此 保留 期 ，dbms_stats 包 提供 了 alter stats history retention 存 储 过 程 。 下 面 是 一 个 
调用 将 保留 期 设置 为 14 天 的 例子 : 

dbms stats.alter stats history retention(retention => 14) 

注意 ， 使 用 alter stats history retention 存 储 过 程 时 ， 下 面 的 值 具 有 特殊 含义 : 

口 NULL 设 置 保留 期 为 默认 值 ; 

口 0 禁用 历史 记录 ; 

口 -1 禁用 历史 记录 的 清除 。 

将 statistics_level 初 始 化 参数 设置 为 typical( 即 默认 值 ) 或 a11 时 , 会 自 动 清除 比 保留 期 指定 的 
时 间 更 旧 的 统计 信息 。 一 旦 有 必要 进行 手工 清除 时 ，dbms_stats 提 供 了 purge_stats 存 储 过 程 。 下 面 的 
调用 清除 了 历史 表 中 所 有 超过 14 天 的 统计 信息 : 

dbms_stats.purge stats(before timestamp => systimestamp - INTERVAL '14' DAY) 

要 执行 alter stats history retention 和 purge_stats 存 储 过 程 ， 你 需要 analyze any 和 analyze any 
dictionary 系 统 权限 。 


7.5 使 用 备份 表 


用 来 管理 系统 统计 信息 的 大 部 分 dbms_stats 存 储 过 程 都 能 够 使 用 数据 字典 或 者 备份 表 进行 工作 。 
但 是 有 一 个 存储 过 程 只 能 使 用 数据 字典 进行 工作 : restore_system_stats 存 储 过 程 。 

尽管 默认 情况 下 所 有 操作 都 是 针对 数据 字典 执行 的 ,但 是 如 果 您 想 要 改 而 使 用 备份 表 , 那么 支持 
备份 表 的 存储 过 程 会 为 你 提供 三 个 参数 。 这 三 个 参数 如 下 所 示 。 

口 stattab 指 定数 据 字典 之 外 的 一 张 表 的 名 称 用 于 存储 统计 信息 。 默 认 值 是 NULL。 

口 statown 指 定 由 stattab 参 数 指定 的 表 所 有 者 。 默 认 值 是 NULL， 此 时 使 用 的 值 是 当前 用 户 。 

口 statid 是 一 个 可 选 的 标识 符 ， 用 来 识别 存储 在 备份 表 中 的 多 组 统计 信息 ， 即 由 stattab 和 

statown 人 参数 指定 的 那些 。 只 有 当 Oracle identifier" 受 支持 时 才 可 用 。 

举例 来 说 , 下 面 的 调用 收集 无 负载 统计 信息 并 将 其 存储 在 名 为 mystats 的 备份 表 中 , 这 张 表 的 所 有 
者 是 system 用 户 : 

dbms_stats.gather_system_stats(gathering_mode => “noworkload '， 


statown => "System ， 
stattab => 'mystats') 


四 参考 Oracle 官 方 文档 SOL Language Reference 中 关于 identifier 的 定义 。 
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要 创建 一 张 备份 表 ， 可 以 借助 dbms_stats 包 中 的 create_stat_table 存 储 过 程 。 创 建 的 关键 是 指定 
备份 表 的 所 有 者 ( 通过 ownname 参 数 ) 和 表 名 ( 通过 stattab 参 数 )。 此 外 ， 可 选 的 tblspace 参 数 指定 将 
表 创 建 在 哪个 表 空间 中 。 如 果 没 有 指定 tblspace 参 数 ， 则 最 终 会 在 用 户 的 默认 表 空 间 中 创建 表 。 下 面 
是 一 个 例子 : 

dbms_stats.create stat table(ownname => User, 


stattab => 'mystats’', 
tblspace => 'users') 


dbms_stats 包 提供 了 drop_stat_table 存 储 过 程 来 删除 一 张 备份 表 。 也 可 以 使 用 正常 的 DROP TABLE 
语句 来 删除 备份 表 。 例 如 : 


dbms_stats.drop stat table(ownname => user, 
stattab => 'mystats') 


7.6 ”管理 操作 的 日 志 记 录 


除了 restore_system_stats 之 外 , 所 有 用 于 管理 系统 统计 信息 的 dbms_stats 过 程 , 都 会 将 一 些 关 于 
它们 的 活动 的 信息 记录 到 数据 字典 中 。 这 一 信息 可 以 通过 dba_optstat_operations 视 图 具体 化 ， 并 且 
从 12.1 版 本 开始 也 可 以 通过 dba_optstat_operation tasks 视 图 查看 。 注 意 ， 在 多 租户 环境 下 ，cdb 的 视 
图 同样 可 用 。 下 面 这 段 来 自 system stats _ logging.sql 和 脚本 输出 的 摘录 展示 了 查询 该 视图 的 一 个 例子 。 
通过 查询 该 视图 ， 可 以 发 现 执 行 了 哪些 操作 ， 它 们 是 什么 时 候 开始 的 ， 以 及 花费 了 多 长 时 间 : 

SOL> VARIABLE now VARCHAR2(14) 

SOL> BEGIN 人 

2 SELECT to char(sysdate, 'YYYYMMDDHH24MISS') INTO :now FROM dual; 
dbms_stats.delete system stats(); 
dbms_ stats.gather system stats('noworkload’ ); 


END; 
/ 


Ow 


90L> SELECT operation, start time, 
2 (end time-start time) DAY(1) TO SECOND(0) AS duration 
3 FROM dba optstat operations 
4 WHERE start time > to date(:now;'YYYYMMDDHH24MISS') 
5 ORDER BY start time; 


OPERATION START_TIME DURATION 
delete system stats 25-SEP-13 16.59.47.679829 +02:00 +0 00:00:00 
gather system stats 25-SEP-13 16.59.47.688208 +02:00 +0 00:00:02 


另外 ， 自 12.1 版 本 起 ， 可 以 看 见 操作 执行 时 使 用 的 参数 。 下 面 的 查询 证 明了 这 一 点 : 


SQLS SELECT XK 
2 FROM dba optstat operations 0， 
3 XMLTable(' /params/param’ 
PASSING XMLType(notes) 
COLUMNS name VARCHAR2(20) PATH '@name', 
Value VARCHAR2(20) PATH '@val'’) x 


中 
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7 WHERE start time > to date(:now,'YYYYMMDDHH24MISS') 
8 AND operation = 'gather system stats'; 


NAME VALUE 
gathering mode noworkload 
interval 60 

statid 

statown 

stattab 


在 12.1 版 本 中 , 也 可 以 通过 dbms_stats 包 的 report single stats_operation 邱 数 提取 出 某 一 操作 的 
细节 。 输 出 支持 不 同 的 格式 (文本 、HTML 以 及 XML )。 下 面 的 查询 演示 了 如 何 生成 一 个 文本 报告 : 


SQL> SELECT dbms stats.report single stats operation(opid => id, 
2 detail level => 'all', 
format => "text") 


WHERE operation = “gather_ system stats' 


3 
4 FROM dba optstat operations 
5 
6 AND start time > to date(:now,'YYYYMMDDHH24MISS'); 


Operation | Operation | Start Time = | End Time | Additional Info | 
Id | | | 
4928 gather system stats | 25-SEP-13 | 25-SEP-13 | Parameters: 

| 16.28.35.528238 | 16.28.37.105673 | [gathering mode: 

| +02:00 | +02:00 | noworkload] 

| | | [interval: 60] 

| | | Lstatids | 

| | | [statown: ] 

| | | [stattab: ] 


同时 要 注意 ,日 志 信息 会 被 与 之 前 描述 的 统计 信息 历史 相同 的 机 制 清 除 掉 。 因 此 两 者 具有 相同 的 
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系统 统计 信息 对 查询 优化 器 估算 的 成 本 有 直接 影响 。 大 部 分 统计 信息 只 要 可 用 就 会 被 一 直 使 用 。 
然而 ， 有 些 统计 信息 只 有 在 查询 优化 器 估算 某 些 特别 的 执行 计划 时 才 会 使 用 。 具 体 来 说 ，mbrc 只 有 
涉及 多 块 读 时 才 会 被 使 用 ; maxthr 和 slavethr 只 有 当 SQL 语 句 被 认为 会 以 并 行 方式 执行 时 才 会 使 用 ， 
本 节 会 举例 说 明 一 些 用 法 。 其 他 用 法 会 在 第 9 章 中 讨论 查询 优化 器 如 何 估算 全 表 扫 描 的 成 本 时 


介绍 。 
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警告 ”本 节 提 供 的 公式 都 没有 被 Oracle 公 开 ,， 但 有 一 个 例外 。 一 些 测试 表明 这 些 公式 能 够 描述 查询 优 
化 器 是 如 何 估算 给 定 操作 的 成 本 的 。 不 管 怎样 ， 都 不 能 证 明 它 们 在 所 有 的 情形 中 都 是 精确 或 
正确 的 。 提供 这 些 公式 的 目的 是 给 你 一 个 关于 系统 统计 信息 是 如 何 影响 查询 优化 器 的 思路 
本 章 描 述 的 系统 统计 信息 仅 从 10.1 版 本 开始 才 可 用 。 如 果 将 初始 化 参数 optimizer _ 
features_enable 设 置 为 9.2.0.8, 查询 优化 器 的 行为 并 不 总 是 与 这 里 描述 的 一 样 - 因为 这 样 的 配 
置 根本 不 常见 ， 因 此 不 再 提供 该 条 件 下 不 同行 为 的 更 多 信息 。 关于 optimizer features_enable 
的 信息 请 参考 第 9 章 . 


当 系 统统 计 信息 可 用 时 ， 查 询 优 化 器 计算 两 个 成 本 : WO 和 CPU。 第 9 章 将 描述 对 于 大 部 分 重要 的 
访问 路 径 ，LIO 成 本 是 如 何 计算 的 。 关 于 CPU 成 本 的 计算 只 有 很 少 的 信息 可 供 访问 。 尽 管 如 此 , 我 们 仍 
能 够 推测 ， 就 CPU 而 言 ， 查 询 优化 器 使 其 每 个 操作 都 关联 一 个 成 本 。 例如 ， 公 式 7-1 是 用 来 计算 访问 
一 个 列 的 CPU 成 本 的 。 

公式 7-1 访问 一 个 列 的 估算 CPU 成 本 依赖 于 这 个 列 在 表 中 的 位 置 。 这 个 公式 给 出 了 访问 一 行 数 
据 的 成 本 。 如 果 访问 了 多 行 ， 则 CPU 的 成 本 会 按 比 例 增加 。 第 16 章 详细 介绍 了 CPU 的 成 本 为 什么 会 与 
列 的 位 置 有 关 

cpu_cost = column_position* 20 

接 下 来 的 例子 基于 cpu_cost_column_access.sql 脚 本 ， 进 一 步 阐 明了 公式 7-1。 首 先 创建 出 一 个 拥有 
9 个 列 的 表 ， 插入 一 行 数据 ， 然 后 通过 EXPLAIN PLAN 语句 ， 将 访问 9 个 列 各 自 的 CPU 成 本 分 别 显示 出 来 ， 
参见 第 10 章 中 关于 此 SQL 语句 的 详细 信息 。 注 意 一 开始 有 35 757 的 初始 CPU 成 本 用 于 访问 表 ， 然 后 接 下 
来 的 每 个 列 ，CPU 的 成 本 都 递增 20。 而 在 同一 时 刻 ，IO 的 成 本 是 恒定 的 。 因 为 所 有 列 都 存储 在 相同 的 
数据 库 块 中 ， 所 以 这 是 合理 的 ， 因 此 读 取 它们 所 需要 的 物理 读 的 数量 对 于 所 有 的 查询 都 是 一 致 的 : 

SQL> CREATE TABLE t (c1 NUMBER, c2 NUMBER, c3 NUMBER, 


2 C4 NUMBER, c5 NUMBER, c6é NUMBER, 
3 C7 NUMBER, c8 NUMBER, c9 NUMBER); 


SQL> INSERT INTO t VALUES (1, 2, 3, 4, 5, 6, 7, 8, 9); 


SQL> EXPLAIN PLAN SET STATEMENT ID 'c1' FOR SELECT c1 FROM t; 
SQL> EXPLAIN PLAN SET STATEMENT ID “c2”FOR SELECT c2 FROM t; 
SQL> EXPLAIN PLAN SET STATEMENT ID “c3”FOR SELECT c3 FROM 七; 
SQL> EXPLAIN PLAN SET STATEMENT ID “c4”FOR SELECT c4 FROM ty; 
SQL> EXPLAIN PLAN SET STATEMENT_ ID “c5”FOR SELECT c5 FROM +t; 
SQL> EXPLAIN PLAN SET STATEMENT ID “c6”FOR SELECT c6 FROM 七 ; 
SQL> EXPLAIN PLAN SET STATEMENT ID “c7”FOR SELECT c7 FROM 七 ; 
SQL> EXPLAIN PLAN SET STATEMENT ID 'c8' FOR SELECT c8 FROM 七 ; 
SQL> EXPLAIN PLAN SET STATEMENT ID 'c9' FOR SELECT c9 FROM 七 ; 


L> SELECT statement id, cpu cost AS total cpu cost, 

2 cpu cost-lag(cpu cost) OVER (ORDER BY statement id) AS cpu_cost 1 coll, 
3 io cost 

4 FROM plan table 

5 WHERE id= 0 

6 ORDER BY statement id; 
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STATEMENT ID TOTAL CPU COST CPU COST 1 COLL I0 COST 


C1 35757 3 
ep 35777 20 3 
C3 35797 20 
C4 35817 20 3 
C5 35837 20 3 
c6 35857 20 3 
cf 35877 20 3 
C8 35897 20 3 
C9 35947 20 多 


IO 和 CPU 成 本 是 按照 不 同 的 测量 单位 来 表示 的 。 很 显然 , 一 个 SQL 语句 的 总 体 成 本 不 能 简单 地 将 
这 些 成 本 累加 计算 。 为 了 解决 这 个 问题 ,查询 优化 器 将 使 用 引入 了 工作 负载 统计 信息 的 公式 7-2。 简 单 
来 说 ，CPU 成 本 除 以 cpuspeed 来 获取 估计 的 消耗 时 间 ， 然 后 除 以 sreadtim 以 使 用 与 io_cost 一 样 的 测量 
单位 来 表示 成 本 。 

公式 7-2 总体 成 本 基于 LO 成 本 和 CPU 成 本 
coOSsf ~ 10 Bo 
cpuspeed : sreadtim:1000 

为 了 使 用 无 负载 统计 信息 计算 整体 成 本 ， 在 公 武 7-2 中 cpuspeed 被 cpuspeednw 蔡 换 ， 还 有 sreadtim 
的 值 由 公式 7-3 计 算出 来 。 简 单 来 讲 ， 为 计算 sreadtim, .公式 7-3 将 定位 磁盘 上 一 个 数据 块 所 需 的 时 间 
与 将 这 个 块 传递 至 数据 库 引 擎 所 需 的 时 间 相 加 。 

公式 7-3 ”如 有 必要 ， sreadtim 会 根据 无 负载 统计 信息 和 数据 库 默 认 的 块 大 小 进行 计算 
db_block_ size 

iotfrspeed 


一 般 而 言 ， 如 果 工 作 负 载 统计 信息 是 可 用 的 ， 查 询 优 化 器 就 会 使 用 它们 而 忽略 无 负载 统计 信息 。 
应 该 清楚 的 是 ,查询 优化 器 会 执行 一 些 健全 性 检查 ,这些 检查 可 能 禁用 工作 负载 统计 信息 或 者 部 分 替 
换 工 作 负载 统计 信息 。 可 以 通过 脚本 system_stats_sanity_checks.sq]l 观 察 到 这 种 行为 。 下 面 是 一 些 观 
察 的 条 目 。 
口 当 mbrc 不 可 用 或 者 设置 为 0 时 ， 查 询 优 化 器 会 忽略 工作 负载 统计 信息 ， 使 用 无 负载 统计 信息 。 
口 当 sreadtim 不 可 用 或 者 设置 为 0 时 , 查询 优化 器 会 使 用 公式 7-3 和 公式 7-4 分 别 重新 计算 sreadtim 
和 Imreadtim 的 值 。 
口 当 mreadtim 不 可 用 时 ,或 者 当 它 没有 sreadtim 的 值 大 时 ， 查 询 优化 器 会 使 用 公式 7-3 和 公式 7-4 
分 别 重 新 计算 sreadtim 和 mreadtim 的 值 。 
公式 7-4 mreadtim 的 计算 基于 无 负载 统计 信息 以 及 数据 库 的 默认 块 大 小 
mbrc.db_block_size 
iotfrspeed 


仅 当 在 exadata 模 式 下 收集 的 无 负载 统计 信息 可 用 时 ， 才 会 出 现 使 用 公式 7-3 和 公式 7-4 的 特例 。 事 


实 上 ， 伴 随 着 这 种 类 型 的 统计 信息 ， 所 有 的 估算 都 是 基于 mbrc、ioseektim 以 及 iotfrspeed 的 。 
在 被 认为 是 并 行 执行 的 SQL 语 句 的 估算 中 ，slavethr 和 maxthr 又 起 到 什么 作用 呢 ? 简 单 而 言 ， 前 


sreadtim ~ ioseektim + 


mreadtim ~ ioseektim + 
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者 可 以 增加 并 行 执行 的 成 本 ， 后 者 可 以 通过 高 并 行 度 降低 并 行 执行 的 成 本 。 接 下 来 会 详细 讨论 一 下 这 
两 组 统计 信息 的 影响 。 

如 果 没 有 设置 slavethr 和 maxthr， 那 么 查询 优化 器 会 认为 一 个 操作 并 行 执行 的 成 本 与 用 于 执行 的 
并 行 度 成 反比 ， 如 公式 7-5 所 示 。 因 此 ， 查询 优化 器 认为 无 论 并 行 度 是 多 少 , 每 个 并 行 运行 的 从 属 进程 
都 能 够 支撑 公式 7-6 计 算出 来 的 吞吐 率 。 

公式 7-5 并 行 JO 成 本 与 并 行 度 成 反比 。 注 意 ， 常 量 0.9 是 一 个 假想 的 因数 ， 可 能 是 考虑 了 并 行 处 
理 过 程 中 不 可 避免 的 竞争 因素 ， 
serial_io_cost 


dop:0.9 


parallel_io_cost~x 


公式 7-6 单个 服务 进程 的 预期 吞吐 滨 ( 以 字 节 每 秒 为 单位 ) 的 计算 建立 在 工作 负载 统计 信息 和 
数据 库 默 认 块 大 小 的 基础 上 
mbrc:db_block _ size 
mreadtim 


mreadthr ~ “1000 

为 了 防止 查询 优化 器 在 估算 并 行 操作 时 过 于 乐观 ， 可 以 通过 slavethr 增 加 估算 的 成 本 。 要 达到 这 
个 目的 ， 可 以 将 slavethzr 设 置 为 一 个 低 于 mreadthz 的 值 ， 后 者 的 值 是 通过 公式 7-6 计 算出 来 的 。 换 句 话 
说 ， 就 是 通知 查询 优化 器 每 个 从 属 进程 的 吞吐 率 要 低 于 默认 值 。 请 注意 ， 反 之 ， 通 过 给 slavethr 设 置 
一 个 高 于 mreadthr 的 值 来 降低 成 本 是 不 可 能 的 。 事 实 上 ， 当 slavethr 和 mreadthr 的 比例 大 于 0.9 ( 公式 
7-5 使 用 的 假想 因数 )， 则 对 查询 优化 器 的 成 本 估算 没有 影响 。 图 7-4 展 示 了 对 于 一 次 全 表 扫 描 ， 将 
slavethz 的 值 设置 为 mreadthz 的 一 半 时 的 影响 。 


健 Slavyethr not set 
Oslavethr=mreadthr/z 


估算 的 MO 成 本 


“oooooooo 
ee44 


图 7-4 使 用 slavethr 和 不 使 用 slavethz 估 算 的 IO 成 本 对 比 ( 由 parallel fts costing.sql 
脚本 产生 的 数据 ) 


应 给 予 slavethr 如 公式 7-7 中 所 示 的 调整 。 注 意 它 与 公式 7-5 的 区 别 : 假想 因数 ( 0.9 ) 只 有 在 其 大 
于 slavethr 和 mreadthr 的 比例 时 才 会 被 使 用 。 

公式 7-7” 当 slavethr 和 mreadthr 的 比例 小 于 0.9 时 ( 关于 k 的 定义 参见 该 公式 注解 )， 发生 的 并 
行 /O 成 本 的 调整 ( 增加 ) 
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serial_io_cost 
Slavethr :k 
mreadthr 


parallel_io_cost~ 
dop .least (0%, 


注意 ”在 公式 7-7 和 公式 7-8 中 ,因数 k 依 赖 于 数据 库 的 版 本 。 直 到 11.2.0.3 版 本 为 止 , 它 的 值 都 是 1000。 
从 11.2.0.4 版 本 开始 ， 它 的 值 变 成 了 1。 因 此 ， 在 11.2.0.3 版 本 中 ，slavethr 和 mreadthr 的 比值 仅 
对 查询 优化 器 估算 的 值 有 非常 小 的 影响 。 基 于 这 个 原因 ， 实 际 上 在 11.2.0.3 版 本 中 ， 大 多 数 时 
候 观 察 不 到 其 影响 。 


如 公式 7-7 明 确 显示 的 , 成 本 和 并 行 度 成 反比 ， 因 此 slavethr 只 能 用 来 增加 成 本 ,不 能 用 于 降低 成 
本 。 实 际 上 ， 真 实 的 资源 消耗 并 不 总 是 与 并 行 度 成 反比 。 事 实 上 ， 因 为 数据 库 服 务 不 会 无 限 扩展 ， 对 
于 高 并 行 度 操 作 估 算 的 成 本 太 低 。 这 恰恰 是 为 什么 maxthr 可 用 的 原因 。 图 7-5 展 示 了 对 于 与 图 7-4 所 列 
举 的 案例 同样 的 案例 ， 设 置 naxthr 对 于 预防 成 本 降 至 某 一 特定 界限 之 下 的 影响 。 注 意 尽 管 最 低 的 成 本 
与 slavethr 无 关 ， 降 低 成 本 在 不 同 的 并 行 度 都 有 发 生 。 


3000 
总 
二 2000 @slavethr not set 
号 Oslavethr=mreadthr/2 
十 
还 1000 
0 
2 6 10 14 18 22 26 30 
并 行 度 
图 7-5 设置 maxthz 的 情况 下 估算 的 IO 成 本 对 照 ( 由 parallel fts_costing.sql 脚 本 产生 
的 数据 ) 


如 图 7-5 所 示 ，maxthr 的 值 随 着 并 行 度 变 得 太 高 而 停止 降低 成 本 。 简 单 来 说 ,查询 优化 器 根据 公式 
7-8 计 算 ， 成 本 不 能 低 于 某 一 特定 的 值 。 

公式 7-8 预期 的 单个 服务 进程 吞吐 率 与 整个 系统 的 最 大 磁盘 IO 吞吐 率 的 比例 限制 并 行 JO 的 成 本 
( 注意 前 面 k 的 定义 ) 


mreadthr 


minimum __ parallel_io_cost~serial_io_cost: 
maxthr :k 
正如 本 节 中 所 讨论 的 ， 系统 统计 信息 使 得 查询 优化 器 能 够 了 解数 据 库 引 擎 所 运行 的 系统 。 这 意味 
着 ， 对 于 一 个 成 功 的 配置 ， 它 们 是 基本 要 素 。 建 议 为 了 产生 执行 计划 的 稳定 性 而 冻结 它们 。 换 言 之 ， 
我 把 它们 看 成 初始 化 参数 。 
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当然 ， 万 一 主要 硬件 或 者 软件 发 生 了 变化 ， 系 统统 计 信息 就 应 该 重新 计算 ， 因 此 应 该 检查 整个 配 
置 情况 。 出 于 检查 的 目的 ， 也 应 该 定期 把 它们 收集 到 备份 表 中 ( 也 就 是 说 使 用 带 有 statown 和 stattab 
参数 的 gather system_stats 存 储 过 程 ) 并 且 验 证 当前 值 与 数据 字典 中 存储 的 值 是 否 有 重大 差别 。 


7.8 小结 


本 章 描述 了 什么 是 系统 统计 信息 以 及 为 何 查 询 优化 器 需要 它们 。 简 单 来 说 ， 它 们 提供 关于 CPU 和 
磁盘 IO 子 系统 的 性 能 信息 。 本 章 还 涉及 如 何 使 用 dbms_stats 包 来 管理 系统 统计 信息 ， 以 及 在 数据 字典 
中 如 何 找到 它们 。 

然而 系统 统计 信息 并 不 完全 足以 描述 查询 优化 器 运行 的 环境 。 查 询 优化 器 还 需要 深入 了 解 存 储 在 
数据 库 中 的 数据 。 出 于 这 个 目的 ， 可 以 使 用 另 一 种 类 型 的 统计 信息 : 对 象 统计 信息 。 下 一 章 将 提供 该 
类 型 的 统计 信息 的 完整 描述 。 


第 8 章 


对 象 统 计 信 息 


对 象 统计 信息 描述 在 数据 库 中 存储 的 数据 。 例 如 ， 它 们 告诉 查询 优化 器 表 中 存储 了 多 少 条 数据 。 
没有 这 些 特定 信息 ， 查 询 优化 器 永远 无 法 做 出 正确 的 决定 ， 例 如 为 小 表 或 者 大 表 ( 或 结果 集 ) 找 出 正 
确 的 联接 方法 。 为 了 说 明 这 一 点 ， 可 以 参考 下 面 的 例子 。 比 如 我 问 你 从 一 个 地 方 到 家 最 快 的 交通 方式 
是 什么 。 是 乘坐 汽车 、 火 车 还 是 飞机 ? 为 什么 不 骑 自 行车 呢 ? 问题 的 关键 是 ， 如 果 不 考虑 我 的 实际 位 
置 以 及 我 的 家 在 哪 ， 你 没 法 得 到 有 效 答案 。 没 有 对 象 统 计 信息 ,查询 优化 器 也 会 存在 相同 的 问题 。 它 
完全 没 法 产生 最 优 的 执行 计划 。 

本 章 首 先 介绍 了 哪些 对 象 统计 信息 可 供 使 用 * 以 及 在 数据 字典 中 如 何 找到 它们 。 随 之 呈现 的 是 
dbms_stats 包 ， 该 包 用 于 收集 、 还 原 、 锁 定 、 对 比 和 删除 统计 信息 。 最 后 ， 介 绍 一 些 用 来 管理 对 象 统 
计 信 息 的 策略 ， 充 分 利用 可 用 的 特性 。 至 于 查询 优化 器 拿 对 象 统计 信息 做 什么 ,在 这 里 只 会 进行 简单 
介绍 。 大 部 分 统计 信息 的 用 途 将 会 在 第 9 章 中 介绍 。 因 为 查询 优化 器 会 同时 使 用 统计 信息 和 初始 化 参 
数 ， 所 以 在 同一 章 中 一 起 描述 它们 再 合适 不 过 了 。 


注意 ”通过 ASSOCIATE STATISTICS 语句 ， 数 据 库 引擎 可 以 将 用 户 定义 的 统计 信息 与 列 、 函 数 、 包 、 类 
型 、 应 用 域 索引 以 及 索引 类 型 相关 联 。 在 需要 时 ， 这 个 SQL 语句 的 功能 非常 强大 ， 尽 管 在 实践 
中 这 项 技术 很 少 会 用 到 。 基 于 这 个 原因 ，ASSOCIATE STATISTICS 在 这 里 就 不 多 讲 了 。 要 查看 相 
关 信 息 ， 请 参考 Oracle Database Data Cartridge Developer’s Guide 手 册 以 及 Expert Oracle 
Practices ( Apress，2010 ) 的 第 7 章 。 


8.1 dbms stats 包 


过 去 ， 对 象 统计 信息 是 由 ANALYZE 语 句 收 集 的 。 现 在 已 经 不 这 样 做 了 。 对 于 收集 对 象 统计 信息 ， 
ANALYZE 语 名 仍然 可 用 ， 但 只 是 用 于 向 后 兼容 性 的 目的 。 自 从 Oracle9 起 ， 推 荐 使 用 dbms _stats 包 替代 。 
实际 上 ,dbms_stats 包 不 仅 提供 更 多 的 新 特性 ,在 某 些 情形 下 它 还 能 提供 更 好 的 统计 信息 。 举 例 来 说 ， 
ANALYZE 语 句 对 统计 信息 收集 提供 的 控制 更 少 ， 不 支持 外 部 表 ， 并 且 对 于 分 区 的 对 象 ， 只 会 对 每 个 
segment 分 别 收 集 统计 信 息 ， 然 后 在 表 / 索 引 级 别提 取出 统计 信息 ( 通常 少 得 可 怜 )， 基 于 以 上 原因 ,本 
章 将 不 涉及 ANALYZE 语 句 。 

认识 到 这 一 点 很 重要 : dbms_stats 包 提供 一 组 全 面 的 用 于 管理 对 象 统计 信息 的 存储 过 程 和 函数 。 
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因为 数据 库 中 有 许多 对 象 , 通过 不 同 的 粒度 来 管理 它们 的 统计 信息 就 显得 非常 重要 。 可 以 选择 为 整个 
数据 库 、 数 据 字 典 、 单 个 模式 、 单 张 表 、 单 个 索引 或 者 是 单独 的 表 或 索引 分 区 来 管理 对 象 统计 信息 。 

默认 情况 下 ，dbms_stats 包 直接 修改 数据 字典 中 的 数据 。 不 过 ， 它 的 许多 存储 过 程 和 函数 ， 也 能 
使 用 存储 在 数据 字典 之 外 的 用 户 定义 的 表 进 行 工作 。 我 将 其 称 为 备份 表 。 

因为 管理 统计 信息 比 单纯 收集 统计 信息 更 为 复杂 ，dbms_stats 包 提供 以 下 关键 特性 ( 见 图 8-1 )。 

口 收集 统计 信息 ， 并 且 可 以 选择 在 覆盖 当前 统计 信息 之 前 将 它们 存储 到 一 张 备份 表 中 。 

口 锁定 和 解锁 存储 在 数据 字典 中 的 对 象 统计 信息 。 

口 将 对 象 统计 信息 从 一 个 分 区 或 子 分 区 复制 到 另外 一 个 分 区 或 子 分 区 。 

口 还 原 数据 字典 中 的 对 象 统计 信息 。 

口 删除 存储 在 数据 字典 或 备份 表 中 的 对 象 统计 信息 。 

口 将 对 象 统 计 信 息 从 数据 字典 导出 到 备份 表 中 。 

口 将 对 象 统计 信息 从 备份 表 导 和 到 数据 字典 中 。 

口 获取 (提取 ) 存储 在 数据 字典 或 备份 表 中 的 对 象 统计 信息 。 

口 设置 (修改 ) 存储 在 数据 字典 或 备份 表 中 的 对 象 统计 信息 。 


获取 
收集 /删除 /设置 


锁定 /解锁 
复制 /还 原 TT | 


通过 数据 迁移 
工具 复制 , 获取 
删除 /设置 


图 8-1 dbms_stats 包 提供 一 组 全 面 的 用 于 管理 对 象 统计 信息 的 功能 


注意 ， 在 数据 库 之 间 移 动 统计 信息 是 借助 通用 的 数据 迁移 工具 ( 例如， 数据 泵 ) 来 完成 的 ， 并 非 
是 使 用 dbms_stats 包 本 身 。 

随 着 粒度 和 执行 操作 的 不 同 , 表 8-1 列 出 了 dbms_stats 包 提供 的 不 同 的 存储 过 程 和 函数 . 举例 来 讲 ， 
如 果 想 在 一 个 单独 的 模式 下 执行 ，dbms_stats 提 供 了 gather_ schema_stats、delete schema_stats、 
lock schema stats、 unlock schema stats、 restore schema stats、 export schema stats 以 及 import_ 


Schema_Sstatss 


表 8-1 dbms_stats 包 提供 的 功能 


特 性 数据 库 数据 字典 模 式 表 ” 索 引 
收集 /删除 Vv Vv Vv VvV Vv 


锁定 /解锁 Vv Vv 
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( 续 ) 
特 性 数据 库 数据 字典 模 式 表 ” 索 引 
复制 Vv 
还 原 Vv VvV V Vv 
导出 /导入 VvV Vv Vv VvV Vv 
获取 /设置 V Vv 


* 对 于 分 区 对 象 ， 将 处 理 限制 到 单个 分 区 是 可 能 的 。 
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对 象 统计 信息 分 为 三 种 类 型 : 表 统 计 信息 、 列 统计 信息 以 及 索引 统计 信息 。 对 于 每 种 类 型 ， 又 分 
为 多 达 三 种 子 类 型 : 表 / 索 引 级 别 统计 信息 、 分 区 级 别 统计 信息 以 及 子 分 区 级 别 统计 信息 。 显 而 易 见 
分 区 和 子 分 区 统计 信息 只 有 当 对 象 分 别 进行 了 分 区 和 划分 了 子 分 区 时 才 可 用 。 

对 象 统计 信息 通过 表 8-2 中 列举 的 数据 字典 视图 来 显示 。 当 然 ， 对 于 每 一 个 视图 都 有 dba 、all, 在 
12.1 多 租户 环境 下 还 有 cdb 版 本 可 用 ， 例 如 dba tab statistics 、all tab statistics 和 cdb tab_ 
statistics。 


表 8-2 显示 对 象 统计 信息 的 数据 字典 视图 关系 表 


对 和 象 表 / 索 引 级 别 统计 信息 分 区 级 别 统计 信息 子 分 区 级 别 统计 信息 
表 user tab statistics user tab statistics user tab statistics 
列 user tab col statistics user part col statistics user subpart col statistics 
user tab histograms user part histograms user subpart histograms 
索引 user ind statistics user ind statistics user ind statistics 


本 节 的 剩余 部 分 描述 在 数据 字典 中 可 访问 的 最 重要 的 对 象 统计 信息 。 出 于 这 一 目的 , 我 使 用 下 面 
的 SQL 语句 创建 了 一 张 测 试 表 。 这 些 SQL 语 句 ， 与 本 节 i 都 可 以 在 脚本 
object statistics.sql 中 找到 : 


CREATE TABLE 七 

AS 

SELECT rownum AS id, 
50+round(dbms_random.normal*4) AS val1， 
100+round(ln(rownum/3.25+2)) AS val2, 
100+round(1ln(rownum/3.25+2)) AS val3, 
dbms_random.string('p' ,250) AS pad 

FROM dual 

CONNECT BY level <= 1000 

ORDER BY dbms random.value; 


UPDATE t SET val1 = NULL WHERE val1 < 0; 
ALTER TABLE t ADD CONSTRAINT t pk PRIMARY KEY (id); 


CREATE INDEX t val1 i ON t (val1); 
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CREATE INDEX t val2 i ON t (val2); 


BEGIN 
dbms stats.gather table stats( 
ownname => User, 
tabname a» "Te, 
estimate percent => 100, 
method opt => 'for columns size skewonly id, val1 size 15, val2, val3 size 5, pad', 
Cascade => TRUE 
); 
END; 
/ 


8.2.1 表 统 计 信 息 
接 下 来 的 查询 展示 了 如 何 获取 对 于 一 张 表 来 说 最 重要 的 表 统计 信息 : 


SQL> SELECT num rows, blocks, empty blocks, avg space, chain cnt, avg row len 
2 FROM user tab statistics 
3 WHERE table name = 'T'; 


NUM ROWS BLOCKS EMPTY BLOCKS AVG SPACE CHAIN CNT AVG ROW LEN 


下 面 是 对 于 查询 返回 的 表 统 计 信息 的 说 明 。 

口 num_rows 是 表 中 的 数据 行 数量 。 

口 blocks 是 表 中 高 水 位 线 以 下 数据 块 的 数量 。 

口 empty_blocks 是 表 中 高 水 位 线 以 上 数据 块 的 数量 。dbms_stats 包 不 会 将 这 个 值 计算 在 内 。 这 个 
值 会 被 设置 为 0 ( 除非 有 另外 一 个 值 已 经 存在 于 数据 字典 中 )。 

口 avg_space 是 表 的 数据 块 中 的 平均 空闲 空间 ( 按 字 节 表示 )。dbms_stats 包 不 会 将 这 个 值 计算 在 
内 。 这 个 值 会 被 设置 为 0 ( 除非 有 另外 一 个 值 已 经 存在 于 数据 字典 中 ) 

口 chain_cnt 是 表 中 链接 和 迁移 到 另 一 个 块 的 数据 行 的 总 数 ( 详 见 第 16 章 )。 即使 查询 优化 需 使 用 
这 个 值 ，dbms_stats 包 也 不 会 将 其 计算 在 内 。 它 会 被 设置 为 0 ( 除非 有 另外 一 个 值 已 经 存在 于 
数据 字典 中 ) 

口 avg_row_len 是 表 中 数据 行 的 平均 大 小 〈 按 字 节 表示 ) 


高 水 位 线 


高 水 位 线 是 段 ( segment ) 中 已 使 用 空间 和 未 使 用 空间 的 分 界线 。 已 使 用 的 块 位 于 高 水 位 线 以 
下 ， 未 使 用 的 块 位 于 高 水 位 线 以 上 。 高 水 位 线 以 上 的 块 从 未 被 使 用 过 或 者 初始 化 过 。 

通常 情况 下 ,请求 空 间 的 操作 (例如 ，INSERT 语 句 ) 只 有 当 高 水 位 线 以 下 没有 更 多 的 空闲 空间 
时 才 会 提高 高 水 位 线 。 这 里 有 一 个 常见 的 例外 是 在 直接 路 径 插 入 期 间 ， 因 为 它们 专门 使 用 高 水 位 线 
以 上 的 块 ( 参考 第 15 章 ) 


释放 空间 的 操作 ( 例如 DELETE 语 句 ) 并 不 会 降低 高 水 位 线 。 它 们 只 是 使 空间 对 其 他 操作 可 用 


8.2 有 哪些 对 象 统计 信息 可 用 187 


如 果 释放 空闲 空间 的 速率 等 于 或 低 于 重用 空间 的 速率 ,那么 使 用 高 水 位 线 以 下 的 数据 块 应 该 是 最 理 
想 的。 否则 ， 高 水 位 线 以 下 的 空闲 空间 会 稳步 增长 。 从 长 远 来 看 ， 这 样 不 仅 会 造成 段 大 小 的 不 必要 
增 大 ， 同 时 也 会 导致 性 能 不 理想 。 实 际 上 ， 全 表 扫 描 会 访问 高 水 位 线 以 下 的 所 有 块 。 即 使 这 些 块 是 
空 的 也 会 扫描 。 应 该 通过 重 构 段 来 解决 这 个 问题 。 


8.2.2 ” 列 统计 信息 


下 面 的 查询 展示 了 如 何 获得 对 于 一 张 表 来 说 最 重要 的 列 统计 信息 
SQL> SELECT column_name AS "NAME", 


2 num distinct AS "#DST", 

3 low value， 

4 high value, 

5 density AS "DENS", 

6 num nulls AS "#NULL", 

7 avg_ col len AS "AVGLEN", 

8 histogram, 

9 num_ buckets AS "#BKT" 

10 FROM user tab col statistics 

11 WHERE table name = '"T'; 
NAME #0DST LOW VALUE HIGH VALUE DENS #NULL AVGLEN HISTOGRAM #BKT 
ID 1000 C102 C20B .00100 0 4 NONE 1 
VAL1 22 C128 C140 .03884 0 3 HYBRID 15 
VAL2 6 C20202 C20207 “00050 0 4 FREQUENCY 6 
VAL3 6 C20202 C20207 .00050 0 4 TOP-FREQUENCY 5 
PAD 1000 202623436F294373342 7E79514A202D4946493 .00100 0 251 HYBRID 254 


37B426574336E4A5B30 66C744E253F36264C69 
2E4F4B53236932303A2 27557A57737C6D4B225 
1215F462B7667457032 9414C442D2544364130 
694174782F7749393B6 612F5B3447405A4E714 
5735646366D20736939 A403B6237592B3D7B67 
335D712B233B3F 7D4D594E766B57 


下 面 是 对 这 个 查询 返回 的 列 统计 信息 的 说 明 。 

口 num_ distinct 是 这 人 ee irate 

口 low value 是 这 个 列 的 最 小 值 。 它 是 通过 内 部 形式 显示 的 。 注 意 ， 对 于 字符 串 列 ( 在 本 例 中 是 
pad 列 )， 只 有 前 32 个 字 节 ( 在 12.1 版 本 中 是 前 64 个 字 节 ) 会 被 使 用 。 

口 high_value 是 这 个 列 的 最 大 值 。 它 是 通过 内 部 形式 显示 的 。 注 意 ， 对 于 字符 串 列 (在 本 例 中 是 
pad 列 )， 只 有 前 32 个 字 节 ( 在 12.1 版 本 中 是 前 64 个 字 节 ) 会 被 使 用 . 


LUE 和 HIGH_VALI 


遗憾 的 是 ， 列 low_value 和 high_value 并 不 容易 去 判读 。 实 际 上 ， 它 们 使 用 数据 库 引 擎 存储 数据 
所 使 用 的 二 进 制 内 部 形式 来 显示 。 要 将 它们 转换 为 可 读 的 值 ， 有 两 种 方式 可 行 。 
第 一 种 方式 ， 使 用 utl raw 包 提供 的 函数 cast to binary double 、cast to binary float 、 
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cast to binary integer、cast to number、 cast to nvarchar2、cast to raw, 以 及 cast to varchar2 
正如 这 些 函 数 的 名 称 所 暗示 的 ,对 于 每 一 种 数据 类 型 ,都 有 对 应 的 函数 用 于 将 内 部 值 转化 为 实际 值 ， 
比如 ， 要 获取 val1 列 的 最 小 值 和 最 大 值 ， 可 以 使 用 以 下 查询 : 

L> SELECT ut] raw.cast to number(low value) AS low value， 

2 utl] raw.cast to number(high value) AS high value 

3 FROM user tab col statistics 
4 
及 


WHERE table name = "TT 
AND column name = 'VAL1'; 


LOW VALUE HIGH VALUE 


第 二 种 方式 ， 使 用 dbms stats 包 提供 的 存储 过 程 convert raw value ( 重 载 了 几 次 )、 
Convert raw_vValue_nvarchar 以 及 convert raw value rowid。 注意 ， 为 避免 使 用 PL/SQL 代 码 块 ， 下 
面 的 查询 使 用 了 版 本 12.1, 使 用 该 版 本 有 可 能 在 WITH 子 句 中 声明 PL/SQL 函 数 和 过 程 。 这 个 查询 的 用 
途 与 之 前 的 查询 ( 在 脚本 object statistics.sql 中 ,可 以 找到 这 个 查询 的 变 体 支持 的 所 有 最 常见 的 
数据 类 型 ) 是 一 样 的 : 

SQL> WITH 

2 FUNCTION convert raw value(p value IN RAW) RETURN NUMBER IS 

3 1 ret NUMBER; 

4 BEGIN 

5 dbms_stats.convert raw value(p value, 1 ret); 

6 RETURN 1 ret; E 

7 END; 
8 SELECT convert raw value(low value) AS low value, 
9 convert raw value(high value) AS high value 
10 FROM user tab col statistics 
11 WHERE table name = 'T' 
12 AND column name = "VAL1' 
13 / 


LOW_VALUE HIGH VALUE 


口 density 是 一 个 0 到 1 之 间 的 小 数 。 值 接近 0 表示 在 这 个 列 上 的 限制 条 件 会 过 滤 掉 大 部 分 记录 。 值 
接近 1 表示 在 这 个 列 上 的 限制 条 件 几 乎 不 会 过 滤 掉 任何 记录 。 如 果 没 有 出 现 直 方 图 , 则 density 
值 为 1/num_distinct。 如果 有 直方 图 出 现 , 则 其 值 的 计算 方式 会 不 同 , 且 依 赖 于 直方 图 的 类 型 。 
不 管 怎样 , 从 10.2.0.4 版 本 起 , 对 于 有 直方 图 的 列 , 这 个 值 仅 用 于 在 optimizer features_enable 
初始 化 参数 设置 为 更 旧 的 版 本 时 保持 向 后 兼容 性 。 

口 num_nulls 是 存储 在 这 个 列 上 的 NULL 值 的 数量 。 

口 avg_col_len 是 以 字 节 表示 的 平均 列 大 小 。 

口 histogram 表 明 这 个 列 上 是 否 有 直方 图 可 供 使 用 ， 以 及 当 直 方 图 可 用 时 直方 图 的 类 型 是 什么 。 
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有 效 的 值 包括 NONE ( 即 没有 直方 图 )、FREQUENCY、HEIGHT BALANCED， 还 有 自 12.1 版 本 开始 可 用 
的 TOP-FREOUENCY 和 HYBRID。 

口 num_puckets 是 直方 图 中 桶 的 数量 。 一 个 桶 ， 或 者 在 统计 信息 里 称 之 为 类 别 ( category )， 是 具 
有 相同 类 型 的 一 组 值 。 正 如 在 下 一 节 中 所 描述 的 ， 直 方 图 由 至 少 一 个 桶 组 成 。 如 果 没 有 直方 
图 ， 这 个 值 设置 为 1。 到 11.2 版 本 为 止 ， 桶 的 最 大 数量 为 234， 而 从 12.1 版 本 开始 起 ， 桶 的 最 大 
数量 为 2048。 


8.2.3 直方 图 


查询 优化 器 以 “数据 是 均匀 分 布 的 ”这 一 原则 为 出 发 点 。 贯 穿 前 面部 分 的 测试 表 存 储 在 ID 列 上 的 
数据 正 是 一 个 均匀 分 布 的 数据 集 的 例子 。 实 际 上 ， 它 将 1~1000 之 间 的 每 个 整数 正好 存储 一 次 。 在 这 种 
情形 下 ， 要 生成 根据 该 列 上 的 谓词 条 件 ( 例如 id BETWEEN 6 AND 19 ) 过 滤 掉 的 记录 数 的 合理 估算 ， 查 
询 优化 器 仅 需 要 描述 谓词 部 分 的 对 象 统计 信息 : 最 小 值 、 最 大 值 以 及 非 重复 值 的 数量 。 

如 果 数 据 并 非 均 匀 分 布 的 ,那么 查询 优化 器 在 没有 额外 信息 的 情况 下 就 无 法 计算 合理 的 估算 。 举 
例 来 说 ,对 于 存储 在 val2 列 上 的 已 知 数据 集合 ( 见 下 面 查询 的 输出 部 分 ), 查询 优化 器 如 何 对 像 val2=105 
这 样 的 谓词 做 出 有 意义 的 估算 ? 答案 是 不 能 ， 因 为 查询 优化 器 丝毫 不 知道 有 大 概 S0% 的 记录 满足 这 个 
谓词 条 件 : a 

SQL> SELECT val2, count(*) 

2 FROM 七 


3 GROUP BY val2 
4 ORDER BY val2; 


VAL2 COUNT(*) 


101 8 
102 25 
103 68 
104 185 
105 502 
106 212 


查询 优化 器 需要 的 关于 非 均匀 分 布 数据 的 额外 信息 被 称 作 直 方 图 ( histogram )。 在 12.1 版 本 之 前 ， 
有 两 种 类 型 的 直方 图 可 用 : 频率 直方 图 ( frequency histogram ) 和 高 度 均衡 直方 图 ( height-balanced 
histogram )。Oracle Database 12.13| 人 了 两 种 额外 的 直方 图 来 取代 高 度 均 衡 直 方 图 : 高 频率 直方 图 ( top 
frequency histogram ) 和 混合 直方 图 (hybrid histogram )。 


警告 只 有 当 收 集 对 象 统计 信息 时 使 用 dbms stats.auto sample size( 在 本 章 稍 后 的 8.3.2 节 会 介绍 这 
个 主题 ) 作为 采样 频率 时 ，dbms stats 包 才 会 创建 高 频率 直方 图 和 混合 直方 图 。 


1. 频率 直方 图 
频率 直方 图 就 是 大 多 数 人 对 直方 图 这 一 概念 的 理解 。 图 8-2 是 频率 直方 图 的 一 个 例子 , 也 是 对 之 前 
查询 返回 数据 的 一 个 直观 图 示 。 
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频率 
A 


200 十 一 185- 


101 102 103 104 105 106 
图 8-2 ”根据 存储 在 val2 列 中 的 数据 集 绘制 的 频率 直方 图 的 图 示 


存储 在 数据 字典 中 的 频率 直方 图 与 这 个 图 示 很 像 。 主 要 的 区 别 是 字典 中 不 是 使 用 频率 ,而 是 使 用 
累积 频率 。 下 面 的 查询 通过 计算 两 个 相 邻 桶 的 值 ( 注意 ，endpoint_number 即 是 累计 频率 ) 之 间 的 差 来 
将 累计 频率 转化 为 频率 : 


SQL> SELECT endpoint value, endpoint number, 
2 endpoint number - lag(endpoint number,1,0) 
3 OVER (ORDER BY endpoint number) AS frequency 
4 FROM user tab histograms 
5 WHERE table name = 'T"' 
6 AND column name = 'VAL2" 
7 ORDER BY endpoint number; 


ENDPOINT VALUE ENDPOINT NUMBER FREQUENCY 


101 8 8 
102 33 25 
103 101 68 
104 286 185 
105 788 502 
106 1000 212 


频率 直方 图 的 核心 特性 如 下 所 述 。 

口 桶 的 数量 ( 换 名 话说， 类 别 的 数量 ) 与 不 重复 值 的 数量 一 致 。 在 像 user tab_histograms 这 样 
的 视图 中 每 个 桶 都 有 一 条 对 应 的 记录 可 用 。 

口 endpoint value 列 提供 其 自身 值 的 一 个 数值 形式 表示 。 因 此 ， 对 于 非 数值 形式 的 数据 类 型 ， 必 
须 将 其 实际 值 编 码 为 一 个 数字 。 根 据 数 据 、 数 据 类 型 以 及 版 本 的 不 同 ， 实 际 值 可 能 在 
endpoint_actual_value 列 (在 之 前 的 输出 中 并 没有 显示 ) 中 可 见 。 要 非常 清楚 地 了 解 存储 在 
直方 图 中 的 值 ， 只 能 根据 前 面 32 个 字 节 (在 12.1 版 本 中 是 64 个 字 节 ) 来 区 分 。 结 果 就 是 拥有 和 较 
长 固定 前 级 的 值 可 能 会 危及 直方 图 的 有 效 性 。 尤 其 是 当 使 用 每 个 字符 可 能 占用 四 个 字 节 的 多 
字 节 字符 集 时 更 是 如 此 。 
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口 endpoint_number 列 提供 值 的 累积 频率 。 要 获得 真正 的 频率 ,必须 减 去 前 一 条 记录 的 endpoint_ 
number 列 的 值 。 


警告 ”假如 动态 采样 用 于 构建 直方 图 ， 则 频率 信息 应 根据 采样 大 小 按 比例 决定 。 要 知道 比例 因子 ， 
请 用 采样 大 小 ( sample size ) 除 以 记录 的 数量 (num rows )。 这 两 个 列 都 是 由 类 似 
user tab statistics 这 样 的 视图 提供 的 。 


接 下 来 的 例子 展示 了 查询 优化 器 如 何 利 用 频率 直方 图 来 精确 估算 一 个 在 val2 列 ( 有 关 EXPLAIN PLAN 
语句 的 详细 信息 ， 请 参见 第 10 章 ) 上 使 用 了 谓词 的 查询 返回 的 记录 数量 ( cardinality ): 


SOL> EXPLAIN PLAN SET STATEMENT ID '101' FOR SELECT * 101; 
SQL> EXPLAIN PLAN SET STATEMENT ID '102' FOR SELECT * FROM t WHERE val2 = 102; 
SQL> EXPLAIN PLAN SET STATEMENT ID '103' FOR SELECT * FROM t WHERE val2 = 103; 

* = 

k 

宁 


FROM t WHERE val2 


SQL> EXPLAIN PLAN SET STATEMENT ID “104”FOR SELECT * FROM 七 WHERE val2 = 104; 
SQL> EXPLAIN PLAN SET STATEMENT_ ID “105” FOR SELECT * FROM t WHERE val2 = 105; 
SQL> EXPLAIN PLAN SET STATEMENT ID '106' FOR SELECT * FROM t WHERE val2 = 106; 


SOL> SELECT statement id, cardinality 
2 FROM plan table 
3 WHERE id = 0; 


STATEMENT_ID CARDINALITY 


101 8 
102 25 
103 68 
104 185 
105 502 
106 212 


在 上 面 的 例子 中 ， 所 有 的 谓词 仅 引用 了 直方 图 中 体现 的 值 。 当 使 用 其 他 值 时 ， 又 会 发 生 什 么 呢 ? 
直到 10.2.0.3 版 本 (包括 10.2.0.3 版 本 在 内 ) 为 止 , 查询 优化 器 都 使 用 1 作为 频率 。 从 10.2.0.4 版 本 起 开始 ， 
有 两 种 不 同 的 情况 需要 考虑 。 第 一 ， 如 果 使 用 的 值 在 最 小 值 和 最 大 值 之 间 , 查询 优化 器 取 直 方 图 中 体 
现 的 所 有 值 中 最 低 的 频率 并 将 其 除 以 2。 第 二 ， 如 果 使 用 的 值 超出 了 直方 图 的 涵盖 范围 ， 则 频率 依赖 
于 到 最 小 值 或 最 大 值 的 距离 。 下 面 的 例子 证 明了 这 一 点 : 


SQL> EXPLAIN PLAN SET STATEMENT ID '096' FOR SELECT * FROM 七 WHERE val2 = 96; 
SQL> EXPLAIN PLAN SET STATEMENT ID '098' FOR SELECT * FROM t WHERE val2 = 98; 
SQL> EXPLAIN PLAN SET STATEMENT ID '100' FOR SELECT * FROM t WHERE val2 = 100; 
SQL> EXPLAIN PLAN SET STATEMENT ID '103.5' FOR SELECT * FROM t WHERE val2 = 103.5; 
SQL> EXPLAIN PLAN SET STATEMENT ID '107' FOR SELECT * FROM t WHERE val2 = 107; 
SQL> EXPLAIN PLAN SET STATEMENT ID '109' FOR SELECT * FROM 七 WHERE val2 = 109; 
SQL> EXPLAIN PLAN SET STATEMENT ID '111' FOR SELECT * FROM 七 WHERE val2 = 111; 


ll 


外 


L> SELECT statement id, cardinality 
2 FROM plan table 

3 WHERE id= 0 

4 ORDER BY statement id; 
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STATEMENT ID CARDINALITY 


2. 高 度 均衡 直方 图 

当 不 重复 值 的 数量 大 于 允许 的 桶 的 最 大 数量 ( 使 用 dbms_stats 包 时 ， 会 有 一 个 硬性 限制 ， 甚 至 有 
可 能 会 指定 一 个 更 低 的 值 ) 时 ， 你 就 无 法 使 用 频率 直方 图 ， 因 为 每 个 桶 只 支持 一 个 单独 的 值 。 此 时 就 
该 高 度 均衡 直方 图 施展 身手 了 。 

要 创建 一 个 高 度 均 衡 直 方 图 ， 考虑 一 下 接 下 来 的 过 程 。 首 先 ,创建 出 一 个 频率 直方 图 。 然后， 如 
图 8-3 所 示 ， 频 率直 方 图 的 值 被 堆积 成 一 “ 堆 "。 最 后 ， 这 个 “ 堆 ” 再 被 分 成 几 个 具有 相同 高 度 的 桶 。 
例如 ， 在 图 8-3 中 ,“ 堆 ”被 分 到 了 五 个 桶 中 。 


图 8-3 ”将 频率 直方 图 转换 为 高 度 均衡 直方 图 


下 面 的 查询 是 一 个 如 何 为 val2 列 生成 一 个 高 度 均 衡 直方 图 的 例子 。 图 8-4 展 示 了 这 个 查询 返回 数据 
的 一 个 图 示 。 注 意 每 个 桶 的 端点 值 正 是 拆 分 数据 出 现 的 点 。 此 外 ， 桶 0 被 添加 进来 用 以 存储 最 小 值 : 
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SQL> SELECT count(*), max(val2) AS endpoint value, endpoint number 

2 FROM ( 
SELECT val2, ntile(5) OVER (ORDER BY val2) AS endpoint number 
FROM +t 


3 
4 
5 ) 
6 GROUP BY endpoint number 
7 ORDER BY endpoint number; 


COUNT(*) ENDPOINT VALUE ENDPOINT NUMBER 


200 104 4 
200 105 2 
200 105 3 
200 106 4 
200 106 3 
累积 频率 端点 值 
A 入 
1000 一 | 106 (端点 号 5) 
| 
; 
| LU 
a 106 (端点 号 4) 
105 (端点 号 3) 
| 
| 
一 + 一 105 (端点 号 2) 
| 
286 一 | 
| 104 (端点 号 1) 
101 一 
33 一 
8 Me | 一 101 (端点 号 0) 
ol 


图 8-4 ”根据 存储 在 val2 列 上 的 数据 集 建立 的 高 度 均衡 直方 图 


针对 图 8-4 中 的 案例 , 接 下 来 的 查询 展示 了 存储 在 数据 字典 中 的 高 度 均衡 直方 图 。 有 趣 的 是 , 并 没 
有 存储 所 有 的 桶 。 之 所 以 没有 存储 所 有 的 桶 是 因为 ， 几 个 拥有 相同 端点 值 的 相 邻 桶 没有 多 大 用 处 。 实 
际 上 ， 从 显示 出 来 的 数据 可 以 推断 出 ， 桶 2 的 端点 值 是 105， 而 桶 4 的 端点 值 为 106。 查 询 结果 有 点 浓缩 
的 意思 。 在 直方 图 中 出 现 多 次 的 值 被 称 为 常见 值 ， 并 且 会 被 查询 优化 器 特殊 处 理 : 
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SELECT endpoint value, endpoint number 


FROM user tab histograms 
WHERE table name = 'T' 
AND column_ name = 'VAL2" 
ORDER BY endpoint number; 


ENDPOINT VALUE ENDPOINT NUMBER 


101 0 
104 1 
105 3 
106 5 
下 面 是 高 度 均 衡 直方 图 的 主要 特性 。 


口 桶 的 数量 少 于 不 重复 值 的 数量 。 对 于 每 一 个 桶 ， 除 非 它 们 进行 了 压缩 ， 否 则 都 在 像 user tab_ 
histograms 这 样 的 视图 中 有 一 条 带 有 端点 号 的 记录 与 之 对 应 。 此 外 ， 端 点 号 0 表明 是 最 小 值 。 

口 endpoint_value 列 给 出 关于 值 本 身 的 数字 表示 形式 。 关 于 这 个 列 的 更 多 信息 ,请 参考 “频率 直 
方 图 ”一 节 中 的 描述 。 

口 endpoint_number 列 给 出 桶 的 编号 。 

口 直方 图 不 存储 值 的 频率 。 

下 面 的 例子 展示 了 当 存 在 合适 的 高 度 均 衡 直方 图 时 查询 优化 器 所 作 的 估算 。 注意 与 频率 直方 图 相 

比 相对 较 低 的 精确 度 : 


SQL> 


EXPLAIN PLAN SET STATEMENT_ ID “101” 
EXPLAIN PLAN SET STATEMENT_ID “102” 
EXPLAIN PLAN SET STATEMENT_ID '103" 
EXPLAIN PLAN SET STATEMENT ID “104" 
EXPLAIN PLAN SET STATEMENT_ID “105” 
EXPLAIN PLAN SET STATEMENT_ID “106” 


SELECT statement id, cardinality 
FROM plan table 
WHERE id = 0; 


STATEMENT_ID CARDINALITY 


400 
300 


FOR 
FOR 
FOR 
FOR 
FOR 
FOR 


SELECT * 
SELECT * 
SELECT * 
SELECT * 
SELECT * 
SELECT * 


FROM 七 WHERE 
FROM 七 WHERE 
FROM 七 WHERE 
FROM 士 WHERE 
FROM 七 WHERE 
FROM t WHERE 


val2 
val2 
val2 
val2 
val2 
val2 


i i i 外 ll 1 


101; 
102s 
103; 
104; 
105; 
106; 


注意 ”你 可 能 认为 关于 值 105 和 106 的 基数 估算 完全 一 样 (400， 因 为 这 两 个 高 频率 值 都 占 了 桶 数量 的 
2/$ )。 但 是 对 于 值 106， 却 不 是 这 样 。 这 是 因为 ， 查 询 优化 器 在 出 现 一 个 常见 值 同 时 也 是 直方 
图 的 最 大 值 时 ， 调 整 了 估算 的 结果 。 


同样 对 于 这 种 类 型 的 直方 图 , 我 们 来 看 一 下 当 使 用 了 直方 图 中 没有 体现 的 值 时 会 发 生 什 么 。 此 时 
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需要 考虑 两 种 完全 不 同 的 情况 。 第 一 ， 如 果 值 在 最 小 值 和 最 大 值 之 间 ， 查 询 优化 器 会 使 用 与 其 他 非常 
见 值 一 样 的 频率 。 第 二 ， 如 果 值 在 直方 图 涵盖 的 值 范围 之 外 ， 则 频率 依赖 于 其 到 最 小 值 或 最 大 值 的 距 
离 。 下 面 的 例子 证 明了 这 一 点 : 


SQL> EXPLAIN PLAN SET STATEMENT_ID '096' FOR SELECT * FROM 七 WHERE val2 = 96; 
SQL> EXPLAIN PLAN SET STATEMENT ID “098” FOR SELECT * FROM 七 WHERE val2 = 98; 
SOL> EXPLAIN PLAN SET STATEMENT ID “100” FOR SELECT * FROM 七 WHERE val2 = 100; 
SQL> EXPLAIN PLAN SET STATEMENT_ID “103.5”FOR SELECT * FROM 七 WHERE val2 = 103.5; 
SQL> EXPLAIN PLAN SET STATEMENT_ID “107”FOR SELECT * FROM 七 WHERE val2 = 107; 
SQL> EXPLAIN PLAN SET STATEMENT_ID “109”FOR SELECT * FROM 七 WHERE val2 = 109; 
SQL> EXPLAIN PLAN SET STATEMENT_ ID "111” FOR SELECT * FROM 七 WHERE val2 = 111; 


SQL> SELECT statement id, cardinality 
2 FROM plan table 
3 WHERE id = 0 
4 ORDER BY statement id; 


STATEMENT_ID CARDINALITY 


096 4 
098 20 
100 40 z 
103.5 50 
107 40 
109 20 
111 I 


就 这 两 种 类 型 直方 图 的 这 些 关键 特性 而 论 , 很 明显 频率 直方 图 要 比 高 度 均衡 直方 图 更 加 精确 。 高 
度 均衡 直方 图 的 主要 问题 不 仅仅 是 精确 度 更 低 ， 而 且 有 时 候 可 能 会 意外 导致 一 个 值 被 当做 常见 值 。 例 
如 ， 在 图 8-4 所 示 的 直方 图 中 ， 桶 4 和 桶 5 之 间 的 拆 分 点 非常 接近 于 值 从 105 变 为 106 的 点 上 。 

因此 ， 即 使 是 数据 分 布 非常 微小 的 变化 也 可 能 导致 一 个 不 同 的 直方 图 以 及 不 同 的 估算 结果 。 在 下 
面 的 例子 中 ， 只 有 20 条 记录 被 更 新 ( 约 占 总 记录 数 的 2% )， 就 展示 了 这 样 的 一 种 情况 : 


SQL> UPDATE t SET val2 = 105 WHERE val2 = 106 AND rownum <= 20; 
SQL> REMARK at this point object statistics are gathered 


SQL> SELECT endpoint value, endpoint number 
2 FROM user tab histograms 
3 WHERE table name = 'T' 
4 AND column name = “VAL2" 
5 ORDER BY endpoint number; 


ENDPOINT VALUE ENDPOINT NUMBER 


101 0 

104 1 

105 4 

106 5 
SQL> EXPLAIN PLAN SET STATEMENT ID '101' FOR SELECT * FROM t WHERE val2 = 101; 
SQL> EXPLAIN PLAN SET STATEMENT ID '102' FOR SELECT * FROM t WHERE val2 = 102; 


SQL> EXPLAIN PLAN SET STATEMENT ID '103' FOR SELECT * FROM 七 WHERE val2 


103; 
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SQL> EXPLAIN PLAN SET STATEMENT ID ‘104' FOR SELECT * FROM 七 WHERE val2 = 104; 
SQL> EXPLAIN PLAN SET STATEMENT ID “105”FOR SELECT * FROM 七 WHERE val2 = 105; 
SQL> EXPLAIN PLAN SET STATEMENT ID '106' FOR SELECT * FROM 七 WHERE val2 = 106; 


SOL> SELECT statement id, cardinality 
2 FROM plan table 
3 WHERE id = 0; 


STATEMENT ID CARDINALITY 


101 80 
102 80 
103 80 
104 80 
105 600 
106 80 


因此 ， 在 实践 中 ,高 度 均 衡 直方 图 可 能 不 仅 会 令 人 误解 ， 同 时 也 会 导致 查询 优化 器 估算 的 不 稳定 
性 。 为 了 不 再 使 用 它们 ， 自 12.1 版 本 开始 ， 高 频率 直方 图 和 混合 直方 图 替代 了 高 度 均衡 直方 图 。 


3. 高 频率 直方 图 

频率 直方 图 的 一 个 关键 特征 是 每 个 值 都 在 直方 图 中 体现 出 来 。 尽 管 这 使 得 这 些 频率 非常 精确 , 但 
是 因为 桶 的 数量 的 限制 ， 有 时 无 法 创建 频率 直方 图 。 高 频率 直方 图 概念 的 真实 意图 ， 就 是 假使 存在 某 
些 代表 占 比 很 小 的 数据 的 值 ， 这 些 值 可 以 被 安全 丢弃 ， 因 为 它们 在 统计 上 无 关 紧 要 。 而 且 如 果 能 够 丢 
弃 足 够 多 的 值 来 避免 超出 桶 的 数量 限制 ， 那 么 就 可 能 会 创建 出 根据 top-n 值 构造 的 高 频率 直方 图 。 

为 了 确定 使 用 n 个 桶 的 直方 图 是 否 足 够 精确 ， 数 据 库 引 擎 检查 这 n 个 值 是 否 至 少 代表 了 百分比 为 p 
的 数据 量 ， 而 p 是 由 公式 8-1 计 算出 来 的 。 例 如 ， 类 似 val3 列 上 建立 的 这 个 高 频率 直方 图 ， 它 有 5 个 桶 ， 
必须 得 代表 至 少 80% ( 100=100/5 ) 的 数据 量 。 

公式 8-1 top-n 值 需要 代表 的 数据 量 的 最 小 百分比 

p=100— 

在 val3 列 的 案例 中 , 五 个 桶 就 足够 了 ， 因 为 从 下 面 查询 的 输出 来 看 ，top-3 的 值 已 经 占 到 行 数 据 量 

的 80% 多 : 


SQL> SELECT val3, count(*) AS frequency, ratio to report(count(*)) OVER ()*100 AS percent 
2 FROM 七 
3 GROUP BY val3 
4 ORDER BY val3; 


VAL3 FREQUENCY PERCENT 


101 8 0.8 
102 25 2.5 
103 68 6.8 
104 185 18.5 
105 502 50.2 
106 212 212 


接 下 来 是 存储 在 数据 字典 中 的 关于 val3 列 的 直方 图 : 
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SQL> SELECT endpoint value, endpoint number, 
2 endpoint number - lag(endpoint number,1,0) 
OVER (ORDER BY endpoint number) AS frequency 
FROM user tab histograms 
WHERE table name = "T' 
AND column name = 'VAL3" 
ORDER BY endpoint number; 


~ Gen 全 LU 


ENDPOINT_VALUE ENDPOINT_NUMBER FREQUENCY 


101 4 1 
103 69 68 
104 254 185 
105 756 502 
106 968 212 


对 比 val2 列 的 频率 直方 图 ， 有 两 点 不 同 。 首 先 ， 代 表 值 102 的 桶 并 不 存在 。 并 且 ， 这 还 是 在 值 102 
的 频率 比值 101 的 频率 高 的 情况 下 。 换 句 话说 , 这 个 直方 图 并 不 代表 top-5 的 值 。 其 次 , 代表 值 101 的 桶 ， 
尽管 等 于 这 个 值 的 数据 只 有 8 条 , 但 是 其 端点 值 endpoint_number 却 等 于 1。 事实 是 任何 一 个 直方 图 必须 
总 是 包含 最 小 值 和 最 大 值 , 如 果 是 像 本 例 这 样 , 两 个 值 中 有 一 个 因为 不 是 top-n 值 的 一 部 分 而 被 丢弃 时 ， 
除 最 小 值 、 最 大 值 以 外 的 值 就 被 丢弃 了 ( 拥有 最 低频 率 的 那 一 个 )， 然 后 最 小 值 /最 大 值 的 频率 被 设置 
为 1。 注意， 在 经 过 这 样 的 操作 之 后 ， 必 须 重新 评估 基于 公式 8-1 的 规则 。 
接 下 来 的 例子 展示 了 这 一 点 ,正如 你 所 期 待 的 ,查询 优化 器 使 用 高 频率 直方 图 执行 的 估算 与 使 用 1 
频率 直方 图 进行 的 估算 之 间 的 区 别 仅 在 于 没有 频率 信息 的 值 (101 和 102 ) 上 : 


SQL> EXPLAIN PLAN SET STATEMENT_ ID “101” FOR SELECT * FROM t WHERE val3 = 101; 
SQL> EXPLAIN PLAN SET STATEMENT_ID '102' FOR SELECT * FROM 七 WHERE val3 = 102; 
SQL> EXPLAIN PLAN SET STATEMENT_ID '103' FOR SELECT * FROM t WHERE val3 = 103; 
SQL> EXPLAIN PLAN SET STATEMENT_ID “104” FOR SELECT * FROM 七 WHERE val3 = 104; 
SQL> EXPLAIN PLAN SET STATEMENT ID '105' FOR SELECT * FROM t WHERE val3 = 105; 
SQL> EXPLAIN PLAN SET STATEMENT_ ID '106' FOR SELECT * FROM t WHERE val3 = 106; 


SQL> SELECT statement id, cardinality 
2 FROM plan table 
3 WHERE id = 0 
4 ORDER BY statement id; 


STATEMENT_ID CARDINALITY 


101 32 
102 32 
103 68 
104 185 
105 502 
106 212 


注意 ， 对 于 值 101 和 102， 其 频率 是 直方 图 显示 的 所 有 值 中 最 低 的 频率 除 以 2 得 到 的 。 注 意 ， 结 果 
是 32， 可 能 并 非 你 期 待 的 34 ( 68/2 )， 因 为 并 非 所 有 的 值 都 在 直方 图 中 体现 了 。 

我 们 来 看 一 下 如 果 使 用 了 直方 图 中 没有 体现 的 值 会 发 生 什么 。 简 单 来 说 ， 与 频率 直方 图 一 样 。 下 
面 的 例子 证 实 了 这 一 点 : 
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SQL> EXPLAIN PLAN SET STATEMENT ID '096' FOR SELECT * FROM t WHERE val3 = 96; 
SQL> EXPLAIN PLAN SET STATEMENT ID '098' FOR SELECT * FROM t WHERE val3 = 98; 
SQL> EXPLAIN PLAN SET STATEMENT ID '100' FOR SELECT * FROM t WHERE val3 = 100; 
SQL> EXPLAIN PLAN SET STATEMENT ID '103.5' FOR SELECT * FROM 七 WHERE val3 = 103.5; 
SQL> EXPLAIN PLAN SET STATEMENT ID '107' FOR SELECT * FROM 七 WHERE val3 = 107; 
SQL> EXPLAIN PLAN SET STATEMENT ID “109”FOR SELECT * FROM 七 WHERE val3 = 109; 
SQL> EXPLAIN PLAN SET STATEMENT_ ID “111” FOR SELECT * FROM 七 WHERE val3 = 111; 


SQL> SELECT statement id，cardinality 
2 FROM plan table 
3 WHERE id = 0 
4 ORDER BY statement id; 


STATEMENT_ID CARDINALITY 


096 1 
098 13 
100 26 
103.5 32 
107 26 
109 43 
114 1 


如 果 不 满足 基于 公式 8-1 的 规则 , 也 就 无 法 创建 频率 直方 图 和 高 频率 直方 图 中 的 任何 一 种 , 数据 库 
引擎 会 创建 一 个 混合 直方 图 。 


4. 混合 直方 图 
混合 直方 图 综合 了 频率 直方 图 和 高 度 均衡 直方 图 的 一 些 特征 。 创建 混合 直方 图 与 创建 高 度 均 衡 直 
方 图 都 是 以 同样 的 方法 开始 的 。 随 后 进行 了 以 下 两 项 重要 的 改进 。 
口 每 个 不 重复 值 都 关联 到 一 个 单独 的 桶 〈 换 句 话说 ， 为 高 度 均衡 直方 图 定义 的 常见 值 的 概念 
不 复 存 在 )。 基 于 该 目的 , 桶 的 限制 被 转移 了 。 结果， 每 个 桶 可 能 会 根据 不 同 数量 的 记录 来 


创建 。 
口 频率 被 加 入 到 每 个 桶 的 端点 值 中 。 因 此 ， 对 于 端点 值 ， 而 且 仅 对 于 端点 值 而 言 ， 就 有 了 某 种 
频率 直方 图 可 用 。 


测试 表 有 两 个 混合 直方 图 。 例如， 我 们 看 一 下 为 val1 列 ( 注意， 该 列 拥 有 22 个 不 同 的 值 ) 创建 的 
那个 混合 直方 图 。 下 面 查 询 的 输出 显示 了 该 混合 直方 图 包含 的 数据 集 : 
SQL> SELECT val1, count(*), rat¥yo to report(count(*)) OVER ()*100 AS percent 
2 FROM 七 


3 GROUP BY valil 
4 ORDER BY vali; 


VAL1 COUNT(*) PERCENT 


39 2 0.2 
41 4 0.4 
42 13 | 
43 pa 这 
44 26 2.6 
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46 66 6.6 
47 86 8.6 
48 81 二 
49 97 9.7 
50 102 Eo Wy 
51 103 10.3 
52 80 8.0 
53 64 6.4 
54 76 26 
55 50 5.0 
56 30 3.0 
57 21 Pe 
58 12 1.2 
59 6 0.6 
60 5 0.5 
63 0.1 


et 那么 不 管 是 频率 直方 图 还 是 高 频率 直方 图 ， 都 无 
法 应 用 。 前 者 不 适用 是 因为 桶 的 数量 小 于 不 重复 值 的 数量 ， 后 者 是 因为 top-10 的 值 仅 代表 约 80% 的 记 
录 ee \ 式 8-1 需 要 代表 90% 的 值 ; 90 = 100-100/10 )。 因 此 ， 就 有 了 提供 以 下 信息 的 混合 直方 图 : 


SQL> SELECT endpoint value, endpoint number, 
2 endpoint number - lag(endpoint number,1,0) 
3 OVER (ORDER BY endpoint number) AS count, 
4 endpoint repeat count 
5 FROM user tab histograms 
6 WHERE table name = “本 
7 AND column name = “VAL1 
8 ORDER BY endpoint number; 


ENDPOINT_VALUE ENDPOINT NUMBER COUNT ENDPOINT REPEAT COUNT 
39 2 2 
44 66 64 26 
45 120 54 54 
46 186 66 66 
47 272 86 86 
48 353 81 81 
49 450 97 97 
50 552 102 102 
屯 655 103 103 
52 735 80 80 
53 799 64 64 
54 875 76 76 
56 955 80 30 
59 994 39 6 
63 1000 6 至 


请 注意 , 在 上 面 的 输出 中 , 一 方面 , endpoint_ be 人 关 和 的 人 
es endpoint_ repeat_count 列 提供 端点 值 的 频率 信息 。 根 据 这 个 信息 ， 由 查询 优化 吉 执 行 的 
端点 值 的 佑 算 就 可 以 做 到 精确 。 下 面 是 一 个 例子 : 


SQL> EXPLAIN PLAN SET STATEMENT_ ID '44' FOR SELECT * FROM t WHERE val1 
SQL> EXPLAIN PLAN SET STATEMENT ID '50' FOR SELECT * FROM t WHERE Val1 


44; 
50; 


外 
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SQL> EXPLAIN PLAN SET STATEMENT_ ID “56”FOR SELECT * FROM 七 WHERE vall = 56; 


SQL> SELECT statement id, cardinality 
2 FROM plan table 
3 WHERE id= 0 
4 ORDER BY statement id; 


STATEMENT_ID CARDINALITY 


44 26 
50 102 
56 30 


提示 “混合 直方 图 提供 的 信息 要 比 高 度 均衡 直方 图 提供 的 信息 好 得 多 。 基 于 这 个 原因 ， 从 12.1 版 本 开 
始 ， 就 可 以 并 且 也 应 该 完全 忽略 掉 高 度 均衡 直方 图 了 。 


5. 无 直方 图 | 

请 注意 ，user_tab_histograms 视 图 为 每 个 没有 直方 图 的 列 显示 了 两 行 数据 ， 这 非常 有 意义 。 这 是 
因为 最 小 值 和 最 大 值 分 别 存 储 在 端点 号 0 和 1 上 。 举 例 来 说 ， 对 于 id 列 的 内 容 ， 没 有 直方 图 可 用 ， 就 会 
显示 为 下 面 的 样子 : 


SQL> SELECT endpoint value, endpoint number 
2 FROM user tab histograms 
3 WHERE table name = 'T' 
4 AND column name = "ID ; 


ENDPOINT VALUE ENDPOINT NUMBER 


8.2.4 扩展 统计 信息 


只 有 当 谓词 条 件 中 使 用 了 未 经 修改 的 列 值 时 ， 上 一 节 中 描述 的 列 统计 信息 和 直方 图 才 会 起 作用 。 
例如 ， 如 果 使 用 了 谓词 country=' Switzerland', 通过 country 列 上 适当 的 列 统计 信息 和 直方 图 , 查询 优 
化 器 应 该 能 够 正确 估算 它 的 选择 率 。 这 是 因为 列 统计 信息 和 直方 图 描述 的 是 country 列 自身 的 值 。 另 一 
方面 , 如 果 使 用 了 谓词 upper(country)='SWITZERLAND' ,查询 优化 器 就 不 再 能 够 直接 从 对 象 统计 信息 和 
直方 图 中 推断 出 选择 率 了 。 当 一 个 谓词 条 件 引 用 了 多 个 列 时 也 会 出 现 类 似 的 问题 。 举 个 例子 ， 如 果 将 
谓词 条 件 country='Denmark' AND langvage='Danish' 应 用 到 一 张 包 含 全 世界 人 口 信息 的 表 上 ， 则 很 可 
能 这 两 个 限制 条 件 都 应 用 到 了 表 中 大 多 数 记 录 的 相同 记录 上 了 。 实 际 上 , 大 多 数 讲 丹麦 语 的 人 生活 在 
丹麦 ,生活 在 丹麦 的 大 多 数 人 讲 丹麦 语 。 换 名 话说 ， 这 两 个 限制 条 件 几 乎 是 宛 余 的 。 这 样 的 列 通常 称 
作 关 联 列 (correlated column )， 并 且 它 们 会 对 查询 优化 器 造成 挑战 。 这 是 因为 没有 任何 对 象 统计 信息 
或 者 直方 图 描述 这 样 互 相依 赖 的 数据 ， 或 者 换 句 话 说, 查询 优化 器 实际 上 是 假设 存储 在 不 同 列 中 的 数 
据 没有 相互 依赖 关系 。 
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自 11.1 版 本 开始 ， 就 可 以 做 到 基于 表达 式 或 者 一 组 列 来 收集 对 象 统计 信息 和 直方 图 来 解决 这 样 的 
问题 。 这 些 新 的 统计 信息 称 作 扩展 统计 信息 。 这 背后 其 实 主要 就 是 根据 一 个 表达 式 或 者 一 组 列 来 创建 
一 个 叫 作 扩展 信息 的 隐藏 列 。 然 后 就 在 这 个 隐藏 列 上 收集 对 象 统计 信息 和 直方 图 。 

这 个 概念 通过 dbms _stats 包 的 create extended stats 国 数 来 实现 。 例 如 ， 通 过 接 下 来 的 查询 创建 
两 个 表达 式 。 第 一 个 是 在 upper(pad) 上， 第 二 个 是 由 列 val2 和 val3 组 成 的 一 个 列 组。 在 测试 表 中 ， 这 
些 列 包含 完全 一 样 的 值 ; 换 句 话 说， 这些 列 是 高 度 关联 的 ( 实际 上 是 完全 关联 的 )。 根 据 定 义 ， 如 下 
面 要 展示 的 ， 表 达 式 或 这 组 列 必须 包含 在 一 对 圆 括号 中 。 注 意 ， 这 个 函数 返回 的 是 由 系统 生成 的 扩展 
言 息 名 称 (一 个 由 SYS_STU 开 头 的 30 个 字 节 的 名 称 ): 


SQL> SELECT dbms stats.create extended stats(ownname => user, 
tabname => 'T', 
3 extension => '(upper(pad))') AS ext1, 
4 dbms_stats.create extended stats(ownname => user, 
5 tabname => 'T', 
6 
7 


extension => '(val2,val3)') AS ext2 
FROM dual; 


SYS_ STUOKSOX64#IO01CKJ5FPGFK3W9 SYS STUPS77EFBJEOTDFMHM8CHP7Q1 


注意 ”生成 扩展 信息 的 这 组 列 不 能 引用 表达 式 或 虚拟 列 。 


显然 ,一旦 扩展 信息 "创建 完毕 ， 数 据 字典 就 可 以 提供 关于 它们 的 信息 。 下 面 的 查询 基于 
user_stat_extensions 视 图 ， 显示 了 已 经 存在 的 测试 表 的 扩展 信息 。 视 图 同时 还 有 dba、all 以 及 在 12.1 
多 租户 环境 下 的 cdb 版 本 : 


SQL> SELECT extension name, extension 
2 FROM user stat extensions 
3 WHERE table name = 'T'; 


EXTENSION NAME EXTENSION 


SYS_STUOKSOX64#IO1CK]J5FPGFK3N9 (UPPER("PAD")) 
SYS_STUPS77EFBJCOTDFMHM8CHP7Q1 ("VAL2", "VAL3") 


如 同 在 接 下 来 的 查询 输出 中 所 示 ， 隐藏 列 和 扩展 信息 的 名 称 相同 。 还 要 注意 扩展 信息 的 定义 是 如 
何 添加 到 列 上 的 : 


SQL> SELECT column name, data type, hidden column, data default 
2 FROM user tab cols 
3 WHERE table name = 'T' 
4 ORDER BY column id; 


COLUMN NAME DATA_TYPE HIDDEN DATA DEFAULT 


加 无 法 创建 超过 20 条 扩展 信息 。 如 果 你 想 创建 超过 20 扩 展 信息 ,那么 就 会 出 现 如 下 错误 : ORA-20008: Number of 


extensions in table<talble>already reaches the upper limit (20)。 
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ID NUMBER NO 
VAL1 NUMBER NO 
VAL2 NUMBER NO 
VAL3 NUMBER NO 
PAD VARCHAR2 NO 


SYS _STUOKSQX64#IO1CKJ5FPGFK3N9 VARCHAR2 YES UPPER("PAD”) 
SYS_STUPS77EFBJCOTDFMHM8CHP7Q1 NUMBER YES SYS_OP_ COMBINED HASH("VAL2","VAL3") 


警告 ”因为 一 组 列 的 扩展 统计 信息 来 自 一 个 散 列 函数 (sys_op_combined hash )， 所 以 这 些 统计 信息 
只 能 够 应 用 于 等 价 谓词 上 。 换 句 话说， 如果 使 用 了 基于 类 似 BETWEEN 以 及 < 或 这样 的 运算 符 的 
谓词 条 件 , 则 查询 优化 器 无 法 利用 扩展 统计 信息 。 一 组 列 的 扩展 统计 信息 也 可 以 用 于 估算 GROUP 
BY 条 件 的 基数 ， 并 且 从 11.2.0.3 版 本 开始 ， 也 可 以 用 于 DISTINCT 运 算 符 和 SELECT 子 句 。 


要 删除 一 个 扩展 信息 ，dbms_stats 包 提供 了 drop_extended _ stats 存储 过 程 。 在 接 下 来 的 例子 中 ， 
PL/SQL 代 码 块 删除 了 之 前 建立 的 两 个 扩展 信息 : 


BEGIN 
dbms_stats.drop extended stats(ownname => user, 
tabname => 'T', 
extension => '(upper(pad))'); 
dbms_stats.drop extended stats(ownname => user, 
tabname => 'T', 
extension => '(val2,val3)'); 
END; 


完全 没有 必要 因为 一 件 小 事 就 决定 哪 一 组 列 适合 在 上 面 创建 扩展 信息 。 下 面 的 方法 可 以 用 于 
11.2.0.2 之 后 的 版 本 中 (在 脚本 seed_col usage.sql 中 有 完整 的 例子 可 供 访 问 )。 

(1) 调用 dbms_stats 包 的 seed_col_usage 存 储 过 程 来 指示 查询 优化 器 记录 以 下 信息 : WHERE 子 句 中 指 
定 的 关于 谓词 的 信息 ，GROUP BY 子 句 中 引用 的 关于 列 的 信息 ， 以 及 从 11.2.0.3 版 本 开始 起 SELECT 子 句 中 
关于 DISTINCT 运 算 符 的 信息 。 做 该 记录 要 么 是 为 了 sqlset_name 和 owner_name 参 数 中 指定 的 SQL 调 优 集 
的 所 有 SQL 语句 ， 要 么 是 为 了 由 time_limit 参 数 指定 的 以 秒 为 单位 的 一 段 时 间 内 进行 了 硬 解析 ( 不 需 
要 执行 ， 因 此 使 用 EXPLAIN PLAN 语句 就 足够 了 ) 的 所 有 SQL 语句 : 


SQL> BEGIN 
2 dbms_stats.seed col usage(sqlset name => NULL, 
owner name => NULL, 
time limit => 30); 
END; 
/ 


(2) 一 旦 记录 过 程 完毕 ， 就 会 调用 dbms_stats 包 的 report_col_usage 函 数 来 报告 列 的 使 用 情况 。 每 
个 列 的 使 用 模式 都 被 报告 出 来 。 例 如 ， 在 下 面 的 输出 中 ，val1 和 val2 列 都 是 一 个 基于 等 值 条 件 的 单 表 
谓词 的 一 部 分 : 


SQL> SELECT dbms stats.report col usage(ownname => user, tabname => 't') 
2 FROM dual; 


Cn 上 


DBMS_STATS.REPORT COL_ USAGE(OWNNAME=>USER, TABNAME=>"T') 
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LEGEND: 

EQ : Used in single table EQuality predicate 
RANGE : Used in single table RANGE predicate 

LIKE : Used in single table LIKE predicate 

NULL : Used in single table is (not) NULL predicate 
EQ_JOIN : Used in EQuality JOIN predicate 

NONEQ JOIN : Used in NON EQuality JOIN predicate 

FILTER : Used in single table FILTER predicate 

JOIN : Used in JOIN predicate 


GROUP BY : Used in GROUP BY expression 


六 #### 检 并 村 扩 ## 闪 社 社 村 村 扩 检 村 村 村 村 村 扩 术 失 划 检 扩 村 村 村 村 并 圭 划 村 村 村 村 村 并 提 守 村 符 提 村 村 村 村 村 失 失 替 失 村 村 提 村 村 并 检 夫 村 失 社 村 村 村 并 夫 划 柑 村 


COLUMN USAGE REPORT FOR CHRIS.T 


ot 


1. VAL1 : EQ 
2. VAL2 : EQ 

3. VAL3 请 

4. (VAL1, VAL2) : FILTER;S 
5. (VAL1, VAL3) : FILTER 
6. (VAL2, VAL3) : GROUP_ BY 


拓 # 提 拉 提 村 入 村 和 村 和 村 入村 入 入 和 村 入 和 入 村 村 村 和 村 和 村 村 入 入 和 失 村 村 

(3) 使 用 dbms_stats 包 的 create_extended_stats 存 储 过 程 来 创建 扩展 信息 。 注意 扩展 信息 自身 的 定 
义 如 果 不 是 作为 参数 来 传递 ， 那么 定义 就 从 记录 过 程 中 存储 的 信息 中 获得 。 因 此 ， 只 需要 模式 和 表 名 
两 个 参数 。 请 注意 ， 在 下 面 的 例子 中 如 何 调用 一 次 create_extended_stats 函 数 就 创建 三 个 扩展 : 


SOL> SELECT dbms stats.create extended stats(ownname => user, tabname => 't') 
2 FROM dual; 


DBMS_STATS.CREATE EXTENDED STATS(OWNNAME=>USER,TABNAME=>"T') 


提 ## 提 扩 检 村 村 村 术 提 夫 村 村 村 检 扩 持 共 村 村 提 村 并 村 夫 拓 持 柑 检 守 提 村 村 村 和 村 守 村 失守 扩 并 夫 扩 村 并 村 并 村 和 社 提 柑 提 埋 持 村 夫 社 入 柑 寺 六 持 并 守 检 提 间 村 并 失守 扩 村 检 检 村 并 


EXTENSIONS FOR CHRIS.T 


1. (VAL1, VAL2) : SYS_STU4K1K3JNH1Z9# L_V93K3DT4 created 
2. (VAL1, VAL3) : SYS STUS574STTDWYBF6PGQN#XHGG] created 
3. (VAL2, VAL3) : SYS_STUPS77EFBJCOTDFMHM8CHP7Q1 created 


提 # 提 # 并 并 柑 和 拉 拓 拓 村 和 入 入 入 村 村 失 拉 拉 拉 术 和 持 科 村 扩 村 折 村 折 折 入 入 科 入 失 失 村 检 拉 拉 村 和 扩 村 入 村 村 村 村 村 村 竺 入村 村 村 村 

(4) 在 创建 完 扩 展 信息 后 ， 重 新 收集 修正 过 的 表 的 对 象 统计 信息 。 

在 12.1 版 本 中 ， 扩 展 信息 也 可 以 由 数据 库 引 擎 自动 创建 。 实 际 上 ， 对 于 利用 统计 信息 反馈 的 SQL 
语句 ， 查 询 优化 器 可 以 创建 一 个 用 于 通知 数据 库 引擎 创建 扩展 信息 的 SQL 计划 指令 〈 SQL plan 
directive )。 这 样 ， 就 可 以 避免 将 来 在 统计 信息 反馈 过 程 中 的 重新 优化 。 完 整 的 例子 可 以 在 脚本 
seed col_usage.sql 中 找到 。 这 里 有 两 个 关键 点 需要 了 解 。 第 一 , 扩展 信息 可 以 创建 并 且 会 自动 创建 。 

和 二 ， 扩 展 信 息 只 有 在 对 象 统计 信息 已 经 收集 的 情况 下 才 可 创建 。 换 句 话说 ,创建 SQL 计 划 指 令 和 创 
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建 扩展 信息 之 间 的 时 间 间 隔 依赖 于 对 象 统 计 信 息 收 集 的 频率 。 

有 意思 的 是 ， 要 注意 扩展 统计 信息 以 另 一 个 特性 为 基础 ， 这 个 特性 是 在 11.1 版 本 中 引入 的 ， 被 称 
作 虚 拟 列 ( virtual column )。 虚拟 列 是 不 存储 数据 而 只 简单 地 通过 基于 其 他 列 的 表达 式 来 生成 其 内 容 的 
列 。 这 在 应 用 程序 频繁 使 用 某 个 给 定 的 表达 式 时 非常 有 用 。 典 型 的 例子 是 ， 在 一 个 VARCHAR2 列 上 应 用 
upper 晴 数 ， 或 者 在 一 个 DATE 列 上 应 用 trunc 函 数 。 如 果 这 些 表达 式 的 使 用 非常 频繁 ， 那 么 像 下 面 这 样 
直接 在 表 上 定义 这 些 表达 式 就 非常 合理 了 : 

SQL> CREATE TABLE persons ( 

2 name VARCHAR2(100), 


3 name upper AS (upper(name)) 
4 ); 


SQL> INSERT INTO persons (name) VALUES ('Michelle'); 


SQL> SELECT name 
2 FROM persons 
3 WHERE name upper = 'MICHELLE'; 


Michelle 

在 第 13 章 中 会 看 到 虚拟 列 上 同样 可 以 建立 索引 。 

虚拟 列 的 主要 问题 是 ,与 扩展 统计 信息 相 比 ， 它 们 会 改变 某 些 SQL 语 句 的 行为 (例如 ，SELECT * 
语句 和 没有 列 清单 的 INSERT 语 句 )， 除 非 它们 被 定义 成 不 可 见 的 〈 虚拟 列 的 可 见 性 自 12.1 版 本 起 可 设 
置 )。 换 名 话说 ， 因 为 扩展 统计 信息 是 基于 隐藏 列 的 ， 它 们 对 于 应 用 程序 来 说 是 完全 透明 的 。 

无 论 虚 拟 列 是 如 何 定义 的 ( 不管 是 通过 用 户 显 式 定义 还 是 通过 扩展 统计 信息 隐 式 定义 )， 关 于 它 
们 的 对 象 统计 信息 和 直方 图 都 会 正常 收集 ， 认 识 到 这 一 点 非常 重要 。 这 样 一 来 ,查询 优化 器 就 获得 了 
关于 数据 的 额外 统计 信息 


SQL 计划 指令 是 在 12.1 版 本 中 引入 的 新 概念 。 它 们 的 用 途 是 帮助 查询 优化 器 应 对 错误 的 估算 。 
要 达到 这 个 目的 ，SQL 计 划 指 令 将 引起 错误 估算 的 表达 式 信息 存储 在 数据 字典 中 。 因 为 它们 并 不 与 
具体 的 SQL 语句 相关 联 ， 所 以 不 仅 多 个 SQL 计划 指令 可 以 同时 应 用 于 一 个 单独 的 SQL 语句 ， 而 且 一 
个 单独 的 SQL 计划 指令 也 可 以 应 用 于 多 个 SQL 语句 

在 某 些 情况 下 ，SQL 计 划 指 令 通知 数据 库 引 擎 自动 创建 扩展 统计 信息 (明确 地 说 ， 列 组 )。 如 
果 无 法 创建 扩展 统计 信息 ， 则 会 通知 查询 优化 器 使 用 动态 采样 。 

当初 始 化 参数 optimizer_ adaptive _ features 的 值 为 TRUE ( 即 默认 值 ) 时 会 局 用 SQL 计划 指令 。 
激活 SQL 计划 指令 时 ， 数 据 库 引 擎 会 自动 维护 ( 例如， 创建 和 清除 ) SQL 计划 指令 。 一 些 管理 操作 
也 可 以 通过 dbms spd 包 手动 执行 

可 用 的 SQL 计划 指令 信息 可 以 通过 dba sql plan directives 和 dba sql plan dir objects 视 图 
来 查询 ( 这 些 视图 的 cdb 版 本 也 可 以 使 用 )。 

ET 
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8.2.5 索引 统计 信息 


在 介绍 索引 统计 信息 之 前 , 我 们 来 根据 图 8-5 简 要 回顾 一 下 索引 的 结构 。 处 于 顶端 的 数据 块 称 为 根 块 
( root block )。 这 个 块 就 是 每 次 查询 的 起 始 块 。 根 块 又 引用 分 支 块 (branch block )。 注 意 ， 也 可 以 将 根 块 
看 作 一 个 分 支 块 。 每 个 分 支 块 又 相应 地 引用 男 一 级 别 的 分 支 块 ， 或 者 如 图 8-5 所 示 ， 引 用 叶子 块 ( leaf 
block )。 叶 子 块 存储 键 值 ( 在 本 例 中 ， 键 值 是 在 6 到 89 之 间 的 一 些 数字 )， 并 存储 引用 数据 的 rowid。 对 于 
任何 一 个 给 定 的 索引 ， 根 块 和 每 个 叶子 块 之 间 的 分 支 块 的 数量 永远 是 相同 的 。 换 名 话说 ， 索 引 永 远 是 平 
衔 的 。 注 意 ， 为 支持 高 效率 的 范围 值 查找 ( 例如， 在 25 和 45 之 间 的 所 有 值 )， 叶 子 块 都 互相 链接 起 来 。 


根 块 


分 
支 
块 

困 

中 | 

A 
叶 red rowid 中 rowid ro 71 rowid 73 rowid 
于 如 fd 时 A a rowid 75 rowid 
块 40 rowi re 1rowid| |89 rowid 


图 8-5 ”基于 B -tree 的 索引 结构 


并 非 所 有 索引 都 具有 这 三 种 类 型 的 块 。 实 际 上 ,分 支 块 只 有 在 根 块 无 法 存储 引用 的 所 有 叶子 块 时 
会 出 现 。 此 外 ， 如 果 索 引 非 常 小 ,那么 它 会 由 一 个 单独 的 块 组 成 ， 并 包含 通常 由 根 块 和 叶子 块 存储 
的 所 有 数据 。 
下 面 的 查询 展示 了 如 何 获取 一 张 表 最 重要 的 索引 统计 信息 : 


SQL> SELECT index_name AS name, 
2 blevel, 
leaf blocks AS leaf blks, 
4 distinct keys AS dst keys, 
5 num_rows, 
6 clustering factor AS clust fact, 
7 avg_leaf blocks per key AS leaf per key, 
8 avg_data blocks per key AS data per key 
9 FROM user ind statistics 
10 WHERE table name = "T'; 


NAME BLEVEL LEAF BLKS DST_KEYS NUM ROWS CLUST _ FACT LEAF PER KEY DATA PER KEY 


T_PK 1 2 1000 1000 979 1 1 
T_VAL1 I 1 2 431 497 478 | 
T_VAL2 I 1 3 6 1000 175 1 29 
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这 个 查询 返回 的 索引 统计 信息 如 下 所 示 。 

口 blevel 是 为 了 访问 叶子 块 而 需要 读 取 的 分 支 块 的 数量 ， 包 含 根 块 在 内 。 

口 leaf blocks 是 索引 的 叶子 块 数量 。 

口 distinct keys 是 索引 中 不 重复 键 值 的 数量 。 

口 num_rows 是 索引 中 键 值 的 数量 。 对 于 主键 ， 这 个 值 与 distinct_keys 相 等 。 

口 clustering_factor 表 明 有 多 少 相 邻 的 索引 条 目 没 有 指向 表 中 相同 的 数据 块 。 如 果 表 和 索引 存 
储 数据 的 顺序 相 类 似 ， 则 群集 因子 ( clustering factor ) 较 低 。 其 最 小 值 是 表 中 非 空 数据 块 的 数 
量 。 如 果 表 和 索引 存储 数据 的 顺序 不 同 ， 则 群集 因子 较 高 。 其 最 大 值 是 索引 中 键 值 的 数量 。 
我 会 在 第 13 章 中 详细 讨论 这 个 值 的 计算 方式 以 及 它 对 性 能 的 影响 。 有 必要 提 一 下 , 对 于 bitmap 
索引 ， 不 会 计算 实际 意义 上 的 群集 因子 。 实 际 上 ， 会 将 其 值 设 置 为 索引 的 键 值 数 量 。 

口 avg_leaf_blocks_per_key 是 存储 一 个 单独 的 键 值 所 需 的 平均 叶子 块 数量 。 这 个 值 是 使 用 公式 
8-2 通 过 其 他 的 统计 信息 计算 得 来 的 。 
公式 8-2 计算 存储 一 个 单独 的 键 值 所 需 叶 子 块 的 平均 数量 

~ leag _blocks 
avg_leaf blocks Per _ key Ne 天 

口 avg_data_blocks_per_key 是 在 表 中 某 个 单独 的 键 值 所 引用 的 数据 块 平均 数量 ,这 个 值 是 使 用 公 
式 8-3 通 过 其 他 的 统计 信息 计算 得 来 的 。 
公式 8-3 计算 某 个 单独 的 键 值 所 引用 的 数据 块 平均 数量 

clustering _ factor 


ave data blocks per Key = 
E a distinct_ keys 


8.2.6 ”分 区 对 象 统计 信息 


分 区 对 象 是 由 有 段 的 集合 组 成 的 逻辑 概念 。 举 例 来 说 ， 下 面 的 SQL 语 句 创 建 一 张 拥 有 16 个 段 的 分 区 
表 , 如 图 8-6 所 示 。 这 16 个 段 是 在 表 空 间 中 实际 存储 数据 的 对 象 ， 四 个 分 区 和 表 仅 是 元 数据 对 象 。 它们 
只 存在 于 数据 字典 中 : 


CREATE TABLE t (id NUMBER, tstamp DATE, pad VARCHAR2(1000)) 
PARTITION BY RANGE (tstamp) 

SUBPARTITION BY HASH (id) 

SUBPARTITION TEMPLATE 


SUBPARTITION sp1， 
SUBPARTITION sp2， 
SUBPARTITION sp3, 
SUBPARTITION sp4 
) 
( 
PARTITION q1 VALUES LESS THAN (to date('2014-04-01' 
PARTITION q2 VALUES LESS THAN (to _ date('2014-07-01' 
PARTITION q3 VALUES LESS THAN (to date('2014-10-01"' 
PARTITION q4 VALUES LESS THAN (to date('2015-01-01’ 
) 


'YYYY-MM-DD'))， 
'YYYY-MM-DD' ))， 
'YYYY-MM-DD'))， 
‘YYYY-MM-DD' )) 


» » vv 
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图 8-6 ”拥有 16 个 段 的 范围 - 散 列 分 区 表 


对 于 分 区 的 对 象 ,数据 库 引 擎 分 别 能 够 在 表 / 索 引 级 别 上 及 分 区 和 子 分 区 级 别 上 处 理 前 面 章 节 讨论 
的 所 有 对 象 统计 信息 ( 换 名 话说 ， 表 统计 信息 、 列 统计 信息 、 直 方 图 和 索引 统计 信息 )。 在 所 有 级 别 
上 拥有 统计 信息 是 有 必要 的 ， 因 为 根据 所 处 理 的 SQL 语句 ， 查 询 优 化 器 着 重 访问 最 能 够 描述 段 的 对 象 
统计 信息 -。 简 言 之 , 仅 在 解析 阶段 查询 优化 器 可 以 确定 是 否 访问 某 个 特定 的 分 区 或 者 子 分 区 时 ,查询 
优化 器 才 使 用 分 区 和 子 分 区 统计 信息 。 否 则 ， 查 询 优 化 器 通常 会 使 用 表 / 索 引 级 别 统 计 信息 。( 但 在 某 
些 情况 下 , 查询 优化 器 在 同一 时 刻 既 使 用 表 / 索 引 级 别 统计 信息 , 也 使 用 分 区 和 子 分 区 级 别 统 计 信息 。) 


8.3 收集 对 象 统计 信息 


为 收集 对 象 统计 信息 ，dbms_stats 包 含有 多 个 存储 过 程 。 使 用 多 个 存储 过 程 是 因为 ， 根 据 不 同 的 
情形 ， 收 集 对 象 统计 信息 的 处 理 过 程 应 该 发 生 在 整个 数据 库 、 数 据 字典 、 模 式 或 者 单独 的 表 级 别 上 。 

口 gather_database_stats 为 整个 数据 库 收集 对 象 统计 信息 。 

口 gather_dictionary_stats 为 数据 字典 收集 对 象 统计 信息 。 注 意 ， 数 据 字典 不 仅 是 由 存储 在 sys 
模式 下 的 对 象 组 成 ， 同 时 也 包括 由 Oracle 为 可 选 组 件 安装 的 其 他 模式 下 的 对 象 。 

口 gather 人 ixed_objects_stats 为 称 作 固 定 表 ( 又 称 为 x$ 表 ) 和 固定 索引 的 特殊 对 象 收集 对 象 统 
计 信 息 ， 它 们 是 数据 字典 的 组 成 部 分 。 固 定 表 ， 通 常用 于 动态 性 能 视图 中 ， 是 仅 存 在 于 内 存 
中 的 结构 。 基 于 这 个 原因 ， 需 要 对 它们 进行 特殊 处 理 。 要 想 知道 这 个 过 程 与 哪些 表 有 关系 ， 
可 以 使 用 下 面 的 查询 。 注 意 ， 并 没有 为 所 有 的 固定 表 收 集 对 象 统计 信息 : 
SELECT name 


FROM v$fixed table 
WHERE type = "TABLE' 


口 gather_schema_stats 为 整个 模式 收集 对 象 统计 信息 。 
口 gather_table_stats 为 表 收 集 包括 列 在 内 的 对 象 统计 信息 ， 还 可 以 为 其 索引 收集 统计 信息 。 
口 gather index_stats 为 索引 收集 对 象 统计 信息 。 


» 


注意 dbms_stats 包 并 不 是 收集 对 象 统计 信息 的 唯一 特性 。 实 际 上 ，CREATE INDEX 和 ALTER INDEX 语 名 
在 创建 索引 时 会 自动 收集 对 象 统计 信息 。 此 外 ， 从 12.1 版 本 开始 ，CTAS 语 句 和 将 数据 插入 到 空 
表 中 的 直接 路 径 插入 也 会 自动 收集 对 象 统计 信息 。 要 知道 由 dbms_stats 包 计算 的 对 象 统计 信息 
要 优先 于 自动 收集 的 统计 信息 。 因 此 ， 不 能 在 任何 情况 下 都 总 是 依赖 自动 收集 统计 信息 。 
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dbms_stats 包 提供 的 存储 过 程 接 受 的 不 同 参数 可 以 分 为 三 种 主要 的 类 型 。 通 过 第 一 组 参数 可 以 指 
定 目 标 对 象 ， 通 过 第 二 组 可 以 指定 收集 的 选项 ， 而 通过 第 三 组 可 以 指定 是 否 在 窗 盖 当前 统计 信息 之 前 
备份 它们 。 表 8-3 总 结 了 在 各 个 存储 过 程 中 可 用 的 不 同 参数 。 接 下 来 的 三 个 小 节 将 详细 描述 每 个 参数 的 
使 用 范围 和 用 法 。 


表 8-3 ”用 于 收集 对 象 统计 信息 的 存储 过 程 的 参数 
参数 数据 库 数据 字典 固定 对 象 模 式 表 索引 


目标 对 象 

ownname vV VvV v 
indname Vv 
tabname 2 

partname Vv Vv 
comp_id Vv 

granularity Vv Vv Vv Vv v 

Cascade Vv Vv Vv V 

gather fixed Vv WA 

gather_sys v 

gather temp V Vv 

options Vv Vv Vv Vv 

objlist 这 VvV Vv 

force Vv Vv Vv 
obj filter list Vv VvV Vv 

收集 选项 

estimate percent 5 这 Vv VvV Vv 
block_ sample VvV Vv Vv Vv 

method opt Vv Vv Vv Vv 

degree Vv Vv VvV Vv Vv 
no_invalidate Vv 4 Vv Vv Vv 
备份 表 

stattab v Vv AAA Vv Vv V 
statid Vv Vv Vv Vv Vv 

statown Vv WA Vv v Vv Vv 


* 表示 从 12.1 版 本 起 开始 可 用 。 


8.3.1 目标 对 象 


目标 对 象 参数 指定 要 为 哪些 对 象 收集 对 象 统计 信息 。 

口 ownname 指 定 要 处 理 的 模式 的 名 称 。 这 个 参数 是 强制 参数 。 
D indname 指 定 要 处 理 的 索引 的 名 称 。 这 个 参数 是 强制 参数 。 
口 tabname 指 定 要 处 理 的 表 的 名 称 。 这 个 参数 是 强制 参数 。 
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口 partname 指 定 要 处 理 的 分 区 或 者 子 分 区 的 名 称 。 如 果 没 有 指定 任何 值 , 则 可 能 会 收集 所 有 分 区 
和 子 分 区 的 对 象 统计 信息 ， 具 体 取 决 于 granularity 参 数 ( 见 下 面 ) 的 取 值 。 默 认 值 为 NULL。 
口 comp id 指定 要 处 理 的 组 件 的 ID。 因 为 组 件 的 ID 无 法 用 于 收集 统计 信息 ， 所 以 会 在 内 部 将 它 转 
换 成 一 组 模式 的 列表 。 要 想 知道 对 于 一 个 给 定 的 组 件 都 处 理 了 哪些 模式 ， 可 以 使 用 下 面 的 查 
询 "。 注 意 这 个 查询 的 输出 受 多 个 因素 的 影响 ， 比 如 版 本 和 实际 安装 的 组 件 等 。sys 和 system 
模式 独立 于 此 参数 ,总 是 会 被 处 理 ,如 果 指 定 了 非法 值 , 则 不 会 返回 错误 信息 ,并 且 sys 和 system 

模式 会 正常 进行 处 理 。 通 过 使 用 默认 值 NULL， 所 有 的 组 件 都 会 被 处 理 : 


SQL> SELECT u.username AS schema name, r.cid AS comp id, r.cname AS comp_name 
2 FROM dba users u, 


3 (SELECT schema#, cid, cname 

4 FROM sys.registry$ 

5 WHERE status IN (1, 3, 5) 

6 AND namespace = “SERVER” 

7 UNION ALL 

8 SELECT s.schema#, s.cid, cname 

9 FROM sys.registry$ r, sys.registry$schemas s 
10 WHERE r.status IN (1,3,5) 

让 AND r.namespace = “SERVER 

12 AND x,é€id = Scid) ¥ 


13 WHERE u.user id = r.schema# 
14 ORDER BY r.cid, u.username; 


SCHEMA_NAME COMP_ID COMP NAME 

SYS APS OLAP Analytic Workspace 

SYS CATALOG Oracle Database Catalog Views 

SYS CATJAVA Oracle Database Java Packages 
APPOQOSSYS CATPROC Oracle Database Packages and Types 
DBSNMP CATPROC Oracle Database Packages and Types 
DIP CATPROC Oracle Database Packages and Types 
GSMADMIN INTERNAL CATPROC Oracle Database Packages and Types 
ORACLE_OCM CATPROC Oracle Database Packages and Types 
OUTLN CATPROC Oracle Database Packages and Types 
SYS CATPROC Oracle Database Packages and Types 
SYSTEM CATPROC Oracle Database Packages and Types 
CTXSYS CONTEXT Oracle Text 

SYS JAVAVM JServer JAVA Virtual Machine 
LBACSYS 0LS Oracle Label Security 

MDSYS ORDIM Oracle Multimedia 

ORDDATA ORDIM Oracle Multimedia 

ORDPLUGINS ORDIM Oracle Multimedia 

ORDSYS ORDIM Oracle Multimedia 

ST INFORMIN SCHEMA ORDIM Oracle Multimedia 

WMSYS OWM Oracle Workspace Manager 

MDSYS SDO Spatial 

ANONYMOUS XDB Oracle XML Database 

XDB XDB Oracle XML Database 


J 遗憾 的 是 , Oracle 并 不 会 使 所 有 必需 的 信息 都 在 数据 字典 中 可 见 。 所 以 , 这 个 查询 是 基于 内 部 表 的 。 系统 权限 select 
any dictionary 能 够 提供 对 必要 的 表 的 访问 权限 
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XS$NULL XDB Oracle XML Database 
SYS XML Oracle XDK 
SYS X00 Oracle OLAP API 


口 granularity 指 定 会 在 哪个 级 别处 理 已 分 区 对 象 的 统计 信息 。 这 个 参数 接受 表 8-4 中 的 值 。 默 认 
值 是 auto ( 默认 值 可 以 修改 ， 参 见 8.4 节 )。 关 于 管理 已 分 区 对 象 的 对 象 统 计 信 息 的 详细 信息 ， 


请 参考 8.7 节 。 
表 8-4 granularity 参 数 接受 的 参数 
值 含 义 

all 收集 表 / 索 引 、 分 区 以 及 子 分 区 的 统计 信息 

auto 收集 表 / 索 引 和 分 区 的 统计 信息 。 只 有 当 表 使 用 列表 或 范围 分 区 时 才 会 收集 子 
分 区 的 统计 信息 

global 只 收集 表 / 索 引 的 统计 信息 

global and partition 收集 表 /索引 和 分 区 的 统计 信息 


approx_global and partition ”与 8lobal and partition 类 似 ,但 是 在 表 /索引 级 别 使 用 提取 的 统计 信息 。 在 
10.2.0.5 版 本 以 及 11.1.0.7 之 后 的 版 本 中 可 用 

partition 只 收集 分 区 的 统计 信息 

subpartition 只 收集 子 分 区 的 统计 信息 


口 cascade 指 定 是 否 处 理 索引 的 数据 。 这 个 参数 接受 的 值 为 TRUE 、FLASE 以 及 dbms_stats.auto_ 
cascade。 后 者 是 一 个 设置 为 NULL 的 常量 值 ， 让 数据 库 引 擎 来 决定 是 否 收集 索引 统计 信息 。 默 
认 值 是 dbms_stats.auto_cascade ( 默认 值 可 以 修改 ， 参 见 8.4 节 )。 

口 gather fixed 指 定 是否 为 固定 表 收 集 对 象 统计 信息 。 这 个 参数 接受 的 值 为 TRUE 和 FALSE。 默 认 
值 是 FALSE。 

口 gather _ sys 指定 是 否 收集 sys 模 式 下 的 数据 。 这 个 参数 接受 的 值 为 TAUE 和 FALSE.。 默 认 值 是 FALSE 

ther tmp 相间 是 否 收 提 虱 阿 直到 业 措 。 和 小 关 鬼 技 刘 的 代为 The 和 SEO 人 汉 FhL 5 
参见 8.5 节 以 获取 更 多 详细 信息 

口 options 指 定 有 哪些 对 象 以 及 是 否 收集 它们 。 这 个 参数 接受 的 值 在 表 8-5 中 列 出 。 但是， 当 这 个 参 
数 与 gather_table_stats 存 储 过 程 一 起 使 用 时 , 只 有 gather 和 gather auto 受 支持 。 默 认 nie , 


表 8-5 ”options 参 数 接受 的 值 


值 含 义 
gather 处 理 所 有 对 象 
gather auto 让 存储 过 程 不 仅 决定 要 处 理 哪 些 对 象 而 且 还 要 决定 如 何 去 处 理 这 些 对 象 。 当 


gather table_stats 存 储 过 程 中 使 用 参数 的 值 为 not 时 , 除了 ownname、 ss 
stattab、statid[ 以 及 statown 以 外 的 所 有 参数 都 会 被 忽略 


gather stale 只 有 包含 过 期 对 象 统计 信息 的 对 象 会 被 处 理 。 注 意 , 不 会 将 没有 对 象 统计 信息 
的 对 象 视 为 过 期 的 

gather empty 只 有 没有 对 象 统计 信息 的 对 象 才 会 被 处 理 

list auto 对 于 所 列举 的 对 象 会 按照 gather auto 选 项 进行 处 理 

list stale 对 于 所 列举 的 对 象 会 按照 gather stale 选 项 进行 处 理 


list empty 对 于 所 列举 的 对 象 会 按照 gather empty 选 项 进行 处 理 
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对 象 统计 信息 的 过 期 
为 识别 出 对 象 统 计 信 息 是 否 过 期 ,数据 库 引 擎 对 每 张 表 上 通过 SQL 语句 修改 的 数据 行 的 数量 进 
行 计 数 ( 约 计 ), 计数 的 ee dba tab modifications 
( 这 个 视图 仅 从 11.2 版 本 开始 才 可 用 )、user tab modifications 来 查看 ,还 可 以 通过 12.1 的 多 租户 环 
境 下 的 cdb_tab_modifications 视 图 来 查看 。 下 面 的 查询 是 一 个 样 例 : 


SOL> SELECT inserts, updates, deletes, truncated 
2 FROM user tab modifications 
3 WHERE table name = 'T'; 


INSERTS UPDATES DELETES TRUNCATED 


775 14200 66 NO 
根据 这 个 信息 ，dbms_stats 包 能 够 确定 与 某 个 对 象 关 联 的 对 象 统计 信息 是 否 过 期 。 在 10. en 
中 ， 必 须 有 至 少 10% 的 数据 行 被 修改 了 才 会 认为 对 象 统计 信息 过 期 。 从 11.1 版 本 开始 ， 可 以 通 
stale_percent 首 选项 来 配置 这 个 阅 值 。 上 默认 值 是 10%。8.5 节 hd 介绍 如 何 修改 这 个 值 
要 小 心 ， 因为 在 10.2.0.5、11.2.0.1 以 及 11.2.0.2 版 本 中 ,通过 Data Pump 导 入 到 一 张 空 表 中 的 数据 
的 计数 和 正常 插入 的 数据 相 比 是 不 正确 的 。 因此， 在 导入 之 后 ， 会 认为 对 象 统 计 信 息 过 期 。 
计数 是 由 数据 库 端的 初始 化 参数 statistics _ level 控制 的 。 如 果 这 个 参数 设置 为 typical ( 也 就 
是 默认 值 ) 或 者 al11， 那 么 计数 为 启用 状态 
ee 
口 objlist 根 据 options 参 数 取 值 的 不 同 , 返回 已 经 处 理 过 的 或 者 即将 要 处 理 的 对 象 的 列表 。 
一 个 基于 dbms_stats 包 中 定义 的 类 型 的 输出 参数 。 举 个 例子 ， a tr 
何 显示 人 处理 过 的 对 象 列表 : 


SOL> DECLARE 
2 1 objlist dbms stats.objecttab; 


3 1 index PLS INTEGER; 

4 BEGIN 

5 dbms_stats.gather schema stats(ownname => 'HR', 

6 objlist => 1 objlist); 
J 1 index := 1 objlist.FIRST; 

8 WHILE 1 index IS NOT NULL 

9 LOOP 

10 dbms_output.put(1_ objlist(l] index).ownname || '.'); 
11 dbms output.put line(l objlist(] index).objname); 
12 1 index := 1 objlist.next(l1 index); 

13 END LOOP; 

14 END; 

15, 


HR .COUNTRIES 
HR .DEPARTMENTS 
HR .EMPLOYEES 
HR.JOBS 

HR.JOB HISTORY 
HR . LOCATIONS 
HR. REGIONS 
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口 force 指 定 是 否 覆 盖 已 锁定 的 统计 信息 。 如 果 将 这 个 参数 设置 为 FALSE ， 而 一 个 用 来 处 理 一 张 单 
独 的 表 或 者 索引 的 存储 过 程 正 在 处 理 锁定 的 统计 信息 , 那么 就 会 引发 一 个 错误 (ORA-20005 )。 
这 个 参数 接受 的 值 为 TRUE 和 FALSE。 可 以 在 8.10 节 中 找到 更 多 关于 锁定 的 统计 信息 的 内 容 。 

口 obj filter list 用 于 指定 只 为 那些 至 少 满足 作为 参数 传递 的 其 中 一 个 过 滤 条 件 的 对 象 收集 统 
计 信 息 。 它 基于 dbms_stats 包 自身 中 定义 的 objecttab 类 型 ,并且 只 在 11.1 及 以 后 的 版 本 中 才 可 
用 。 下面 的 PL/SQL 代 码 块 展示 了 如 何 为 HR 模式 下 的 所 有 表 和 SH 模 式 下 的 所 有 表 以 及 使 用 字 
母 C 开 头 的 对 象 收 集 统 计 信 息 : 

DECLARE 


1 filter dbms_stats.objecttab := dbms_stats.objecttab(); 
BEGIN 
1 filter.extend(2); 


1 filter(1).ownname := 'HR'; 
1 filter(2).ownname := 'SH'; 
1 filter(2).objname := 'C%'; 
dbms_stats.gather database stats(obj filter list => 1 filter, 
options => 'gather'’); 
END; 


8.3.2 ”收集 选项 


在 表 8-2 中 列 出 的 收集 选项 参数 指定 了 收集 统计 信息 的 过 程 如 何 进行 ， 收 集 哪些 类 型 的 列 统 计 信 
息 ， 以 及 是 否 使 从 属 SQL 游 标 失效 。 各 个 选项 如 下 所 示 。 

口 estimate_percent 指 定 收集 统计 信息 时 是 否 使 用 采样 有效 值 为 0.000001 到 100 之 间 的 十 进 制 数 
字 。 当 值 为 100 时 , 其 含义 与 NULL 一 样 , 意味 着 不 进行 采样 。 常 量 dbms_stats.auto_sample_size,， 
也 就 是 默认 值 ( 这 个 默认 值 可 以 修改 ,参见 8.4 节 ), 会 让 存储 过 程 来 决定 采样 大 小 。 从 11.1 版 
本 开始 ， 推 荐 使 用 这 个 值 。 实 际 上 ,在 大 多 数 情况 下 ， 使 用 这 个 默认 值 不 仅 使 收集 的 统计 信 
息 比 使 用 类 似 10% 的 采样 率 进 行 收 集 要 更 加 精确 ， 而 且 也 更 加 快速 。 这 是 因为 在 11.1 版 本 中 引 
入 了 一 种 全 新 的 算法 , 而 且 这 种 算法 只 能 在 指定 参数 值 为 dbms_stats.auto_ sample_size 时 才 可 
以 使 用 。 同 时 也 要 指出 ， 因 为 这 个 新 的 算法 需要 对 收集 统计 信息 的 表 执 行 全 表 扫 描 ， 这 在 磁 
盘 1/0 子 系统 相对 缓慢 的 系统 上 可 能 会 花费 很 长 时 间 。 还 要 注意 ， 某 些 特 性 ( 高 频率 直方 图 、 
混合 直方 图 ， 还 有 增 量 统计 信息 ) 要 求 指定 dbms_stats.auto_sample_size。 有 一 点 很 重要 , 将 
一 个 十 进 制 数 字 作 为 参数 传递 进来 时 ， 由 参数 estimate_percent 指 定 的 值 只 不 过 是 用 于 收集 统 
计 信 息 的 最 小 百分比 。 事 实 上 ， 正 如 下 例 所 示 ， 如 果 dbms_stats 包 认为 由 estimate_percent 指 
定 的 值 过 小 ， 那 么 程序 包 可 能 会 自动 增 大 这 个 值 。 假 如 不 使 用 dbms_stats.auto_sample_size 
进行 收集 ， 可 以 使 用 较 小 的 百分比 来 加 速 对 象 统计 信息 的 收集 ; 一 般 来 说 小 于 10 个 百分点 就 
比较 合适 。 对 于 特大 的 表 ，0.5 个 百分点 、0.1 个 百分点 ， 或 者 更 小 的 值 也 不 会 有 问题 。 实 际 上 
的 最 佳 值 取决 于 数据 分 布 情况 。 如 果 不 确定 该 选 什么 ， 干 脆 就 尝试 不 同 的 估算 百分比 然后 比 
较 收 集 的 统计 信息 。 这 样 ， 你 可 能 会 在 性 能 和 精确 度 之 间 找 到 一 个 最 佳 折 囊 点。 注意， 使 用 
小 的 估算 百分比 可 能 不 会 产生 稳定 的 统计 信息 。 因 为 如 果 收 集 统计 信息 是 在 数据 库 或 模式 级 
别 上 执行 ， 则 过 小 的 值 会 被 自动 增 大 ， 估 算 的 百分比 应 该 按 最 大 的 那 张 表 来 选择 。 顺 便 提 一 
下 ,在 外 部 表 上 采样 是 不 受 支 持 的 : 
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SQL> BEGIN 
2 dbms_stats.gather schema_stats(ownname => User, 
3 estimate percent => 0.5); 
4 END; 
5 尖 


SQL> SELECT table name, sample size, num rows, 
2 round(sample_ size/num rows*100,1) AS "%" 
3 FROM user tables 
4 WHERE num Tows > 0 
5 ORDER BY table name; 


TABLE_NAME SAMPLE_SIZE NUM_ROWS % 
CAL MONTH_SALES MV 48 48 100.0 
CHANNELS 5 5 100.0 
COSTS 4975 81391 6.1 
COUNTRIES 23 23 100.0 
CUSTOMERS 5435 55002 9.9 
FWEEK_PSCAT_SALES MV 4742 11001 43.1 
PRODUCTS 72 72 100.0 
PROMOTIONS 503 503 100.0 
SALES 4639 927890 0.5 
SALES TRANSACTIONS EXT 916039 916039 100.0 
TIMES 1826 1826 100.0 


口 block_sample 指 定 是 将 行 级 采样 还 是 块 级 采样 用 于 统计 信息 的 收集 过 程 。 尽管 行 级 采样 更 加 精 
确 ， 但 是 块 级 采样 更 加 迅速 。 因 此 ， 只 有 确定 数据 是 随机 分 布 时 才 应 该 使 用 块 级 采样 。 这 个 
参数 接受 的 值 为 TRUE 和 FALSE。 默 认 值 是 FALSE。 自 11.1 版 本 开始 ， 这 个 参数 只 有 在 estimate_ 
percent 参 数 的 值 没有 设置 为 dbms_stats.auto_sample size 时 才 会 出 现 。 

口 method_ opt 指定 是 否 收集 列 统计 信息 和 直方 图 以 及 如 何 收集 它们 。 下 面 是 三 种 典型 的 用 例 。 
和 为 所 有 列 ” 收 集 列 统计 信息 和 直方 图 。 所 有 直方 图 都 按照 相同 的 size_clause 参 数值 创建 。 如 

果 指 定 的 值 为 1， 则 不 会 创建 任何 直方 图 。 语 法 如 图 8-7 所 示 。 举 个 例子 , 通过 使 用 值 for all 
columns size 254， 会 为 每 个 列 创建 一 个 拥有 最 高 2$4 个 桶 的 直方 图 。 


size_clause 


图 8-7 使 用 具有 单一 取 值 的 size_clause 参 数 为 所 有 列 收集 列 统计 信息 和 直方 图 ( 见 表 
8-5 ) 


indexed 


hidden 


中 为 简单 起 见 ， 我 不 会 描述 所 有 的 可 能 性 ， 因 为 其 中 许多 要 么 是 元 余 的 ， 要么 是 在 实践 中 应 用 受 限 的 。 

名 实际 上 ,通过 选项 indexed 和 hidden， 可 以 限制 仅 为 索引 列 和 隐藏 列 收集 统计 信息 。 一 般 来 说 ， 对 象 统计 信息 应 该 
对 所 有 列 都 可 用 。 基 于 这 个 原因 ， 应 该 避免 使 用 这 两 个 选项 ( 因此 在 图 8-7 中 它们 被 标记 为 灰色 )。 如 果 对 于 某 些 
列 来 说 不 需要 对 象 统 计 信息 ， 则 应 该 转 而 使 用 图 8-8 中 描述 的 语法 。 使 用 hidden 选 项 确实 有 一 个 合理 的 理由 ， 那 就 
是 为 某 个 作为 扩展 而 刚刚 加 入 到 表 中 的 虚拟 列 收 集 统计 信息 。 
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和 在 所 有 列 上 收集 列 统计 信息 并 在 一 部 分 列 上 收集 直方 图 。 所 有 直方 图 都 按照 相同 的 
size_clause 参 数值 创建 。 语 法 为 图 8-7 和 图 8-8 的 一 个 组 合 : 前 者 指定 列 统计 信息 的 收集 ， 后 
者 指定 直方 图 的 收集 。 举 个 例子 ， 指 定 “for all columns size 1 for columns size 254 coll” 会 
使 得 系统 在 每 个 列 上 收集 列 统计 信息 并 只 在 coll 列 上 收集 一 个 最 多 具有 254 个 桶 的 直方 图 


由 Size_clause 攻 
column_clause 


| 


图 8-8 ”只 为 一 部 分 列 收集 列 统计 信息 和 直方 图 ， 但 为 size_clause 参 数 使 用 不 同 的 值 ( 见 
表 8-6 ) 。 对 于 没有 明确 指明 size_clause 参 数 的 列 ， 使 用 默认 的 size clause 参 数 
( 即 本 图 中 左边 的 那个 ) 。 如 果 没 有 指定 列 ， 则 不 会 收集 任何 列 统计 信息 。 
column_clause 参 数 可 以 是 一 个 列 名 、 一 个 扩展 名 或 者 一 个 扩展 信息 。 如 果 指 定 了 
一 个 不 存在 的 扩展 信息 ， 就 会 自动 创建 新 的 扩展 信息 。 这 个 语法 只 能 在 调用 
gather table_stats 存 储 过 程 时 才 有 效 


for columns 


表 8-6 ”size_clause 参 数 接受 的 值 


值 含义 

size n 指明 最 大 的 桶 数量 。 如 果 指定 了 size 1， 则 不 会 创建 直方 图 。 但 无 论 怎样 ， 列 统计 信息 
都 是 正常 收集 的 

size skewonly ”只 为 含有 牌 斜 数据 的 列 收集 直 放 图 。 桶 的 数量 由 系统 自动 确定 

size auto 只 为 含有 垩 斜 数据 的 列 收集 直方 图 ;就 像 skewonly 一 样 ， 此 外 ， 还 为 那些 在 WHERE 条 件 中 


被 引用 的 列 收集 直方 图 。 第 二 个 条 件 基于 列 使 用 的 历史 信息 。 桶 的 数量 由 系统 自动 确定 
size repeat ”刷新 可 用 的 直方 图 


只 为 一 部 分 列 收集 列 统计 信息 和 直方 图 ， 并 上 且 为 size_clause 参 数 使 用 不 同 的 值 。 语 法 如 图 
8-8 所 示 。 举 例 来 说 ， 指 定 for columns size 1 id，col1 size 100，col2 size 5，c013 会 使 
得 系统 在 四 个 列 上 收集 列 统计 信息 , 但 是 只 会 在 列 col1 和 col2 上 分 别 收集 最 多 有 100 个 桶 和 5 
个 桶 的 直方 图 

这 个 参数 的 默认 值 是 for all columns size auto (默认 值 可 以 修改 ， 参 见 8.4 节 )。 为 简单 起 见 ， 
使 用 size skewonly 或 者 size auto。 如 果 执 行 得 太 慢 或 者 选择 的 桶 数 不 合 理 ( 或 者 所 需要 的 直方 图 根 
本 没有 创建 )， 那 么 就 手工 指定 列 的 列表 。 如 果 指 定 了 NULL， 则 会 使 用 for all columns size 1。 


列 使 用 历史 
dbms_stats 包 依赖 于 列 使 用 历史 来 决定 哪些 列 的 直方 图 是 有 帮助 的 。 为 收集 历史 ， 当 产生 一 
个 新 的 执行 计划 时 ， 查 询 优 化 器 会 跟踪 哪些 列 被 WHERE 子 句 引 用 了 ， 并 会 存储 它 在 SGA 中 找到 的 
人 信息。 然后， 每 隔 一 定时 间 ， 数据 库 引 擎 会 将 这 些 信息 存储 在 数据 字典 表 col usage$ 中 。 通 过 执 
行 类 似 下 面 这 样 的 基于 内 部 数据 字典 表 的 查询 ( 该 查询 可 以 在 col usage.sql 脚 本 中 找到 )， 就 可 
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以 知道 哪些 列 被 NHERE 子 名 引用 了 以 及 使 用 的 是 哪 种 类 型 的 谓词 。timestamp 列 表明 了 最 近 使 用 的 
时 间 。 其 他 列 为 硬 解 析 次 数 ( 实际 上 ， 提供 相同 信息 并 接连 不 断 执 行 的 硬 解 析 不 包括 在 内 ) 的 计 
数 。 从 未 被 NHERE 子 名 引用 过 的 列 不 会 出 现在 col usage$ 表 中 ， 所以, 在 输出 中 除了 name 之 外 ， 其 
他 列 值 都 为 空 


SQL> SELECT c.name, cu.timestamp, 
这 cu.equality preds AS equality, cu.equijoin preds AS equijoin, 
3 cu.nonequijoin preds AS noneequijoin, cu.range preds AS range, 
4 cu.like preds AS "LIKE", cu.null preds AS "NULL" 
5 FROM sys.col$ c¢, sys.col usage$ cu, sys.obj$ o, dba users u 
6 WHERE c.obj# = cu.obj# (+) 
7 Cc.intcol# = cu.intcol# (+) 
8 C.obj# = 0.obj# 
0.0wner# = U.user id 
10 AND o.name = 'T' 
U.username = User 
R BY c.col#; 


NAME TIMESTAMP EQUALITY EQUIJOIN NONEEQUIJOIN RANGE LIKE NULL 


ID 27-MAY-14 4 2 9 0 0 0 
VAL1 27-MAY-14 1 0 0 0 0 0 
VAL2 

VAL3 27-MAY-14 1 1 0 0 0 0 
PAD 27-MAY-14 0 0 0 1 0 0 


自 11.2.0.2 版 本 开始 ,dbms_stats 包 的 report col _ usage 函 数 使 得 对 col usage$ 信 息 的 选择 变 得 更 
加 容易 了 -。 注意 ， 这 是 在 8.2.4 节 中 讨论 过 的 相同 函数 。 但 是 要 知道 ， 如 果 没有 使 用 seed col usage 
函数 ，Teport_ col _usage 子 数 返 回 的 报告 不 会 包含 关于 潜在 列 组 的 信息 。 下 面 的 查询 展示 了 一 个 例 
子 ， 并 截取 了 一 段 输出 : 


SQL> SELECT dbms stats.report col _ usage(ownname => User，tabname => 't') 
2 FROM dual; 


COLUMN USAGE REPORT FOR CHRIS.T 


1 :10 : EQ EQ JOIN 
2. PAD : RANGE 

3. VALL1 : EQ 

4. VAL3 : EQ EQ JOIN 


此 外 ， 从 11.2.0.2 版 本 开始 ，dbms_stats 包 还 提供 了 一 种 重 置 col usage$ 表 内 容 的 方法 。 可 以 通 
过 使 用 reset_col usage 存储 过 程 来 达到 此 目的 
| 
口 degree 指 定 为 一 个 单独 对 象 收 集 统计 信息 所 使 用 的 并 行 度 。 要 使 用 在 表 /索引 级 别 定义 的 并 行 
度 ， 请 将 这 个 值 指定 为 NULL。 要 让 存储 过 程 自行 决定 并 行 度 ， 指 定 这 个 值 为 常量 
dbms_stats.default_degree。 其 默认 值 为 NULL ( 这 个 默认 值 可 以 修改 ， 参见 8.4 节 )。 注 意 处 理 
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多 个 对 象 时 是 串 行 执行 的 ， 除 非 使 用 了 并 行 统计 信息 收集 。 这 意味 着 并 行 化 只 对 加 速 大 型 对 
象 统计 信息 的 收集 起 作用 。 要 在 同时 处 理 多 个 对 象 时 使 用 并 行 化 ， 则 有 必要 进行 手工 并 行 化 
(也 就 是 说 ， ee 参考 第 15 章 获取 更 多 关于 并 行 处 理 的 详细 信息 。 并 行 收集 
对 象 统计 信息 只 在 企业 版 中 可 用 。 


并 行 统计 信息 收集 


默认 情况 下 ，dbms_stats 包 只 会 并 行 化 在 表 或 者 分 区 级 别 ( 根据 degree 参 数 ) 的 收集 过 程 。 也 
会 


就 是 说 ,在 任意 给 定 的 时 间 点 ， 只 会 处 理 一 个 单独 的 表 或 分 区 。 如 果 数 据 库 服务 器 拥有 大 量 空闲 资 
源 ， 而 且 需 要 处 理 的 表 或 分 区 很 多 ， 这 种 情况 下 同时 处 理 它们 或 许 比 较 合 理 。 基 于 这 个 目的 ， 自 
11.2.0.2 版 本 开始 ，Oracle Database 提 供 了 一 种 称 为 并 行 统计 信息 收集 ( concurrent statistics gathering ) 
的 新 的 收集 模式 

并 行 统计 信息 收集 是 在 gather * stats 存 储 过 程 中 实现 的 。 要 控制 它 ， 可 以 使 用 concurrent 首 
选项 。 根据 你 所 运行 的 版 本 ， 可 以 将 它 设置 为 下 列 值 

口 11.2: 设置 为 FALSE 会 禁用 这 个 特性 ( 这 是 默认 值 )， 反 之 ,设置 为 TRUE 会 启用 这 个 特性 

口 12.1: 设置 为 OFF 会 禁用 这 个 特性 ( 这 是 默认 值 )， 设置 为 MANUAL 则 只 为 手动 统计 信息 收集 启用 
这 个 特性 , 设置 为 AUTOMATIC 只 为 自动 统计 信息 收集 启用 这 个 特性 ,而 设置 为 ALL 会 为 所 有 类 型 
的 统计 信息 收集 启用 这 个 特性 。 

要 想 利 用 并 行 统计 信息 收集 ， 必 须 满足 以 下 要 求 

口 初始 化 参数 job queue processes 的 值 至 少 应 设置 为 4。 这 是 因为 同时 处 理 多 个 表 或 者 分 区 时 ， 
dbms_stats 包 会 向 Scheduler 提 交 一 定数 量 的 任务 。 

口 Resource Manager 应 该 是 启用 状态 。 因 为 dbms_stats 包 并 不 会 控制 同时 运行 多 少 个 并 发 任务 ， 
所 以 ， 如 果 没有 Resource Manager， 系 统 的 负载 可 能 会 超出 控制 范围 。 实 际 上 ， 并 行 统计 信息 
收集 依赖 于 Scheduler 和 Resource Manager 来 生成 最 佳 负载 

口 提交 收集 任务 的 用 户 必须 拥有 dba 角 色 或 者 拥有 以 下 权限 : CREATE JOB、MANAGE SCHEDULER 以 
及 MANAGE ANY QUEUE 

a 


口 no_invalidate 指 定 是 否 使 依赖 于 所 处 理 对 象 的 游标 失效 ， 并 进而 指定 是 否 禁止 这 些 游标 在 未 
来 继续 使 用 。 这 个 参数 接受 的 值 为 TRUE 、FALSE 以 及 dbms_stats.auto invalidate。 将 这 个 参数 
设置 为 TRUE 时 , 依赖 于 更 改 的 对 象 统计 信息 的 游标 不 会 失效 , 因此 在 未 来 的 执行 中 仍然 可 以 继 
续 使 用 这 些 游 标 。 而 男 一 方面 ， 如 果 将 它 设置 为 FALSE， 所 有 相关 的 游标 会 立即 失效 。 如 果 使 
用 值 dbms_stats.auto invalidate ( 也 就 是 一 个 等 于 NULL 的 常量 ), 那么 相关 的 游标 会 在 一 段 时 
间 后 失效 。 最 后 一 种 选项 有 利于 避免 重新 解析 的 集中 出 现 。 默 认 值 是 dbms_stats.auto_ 
invalidate ( 这 个 默认 值 可 以 修改 ， 参 见 8.4 节 )。 

使 用 了 dbms stats.auto invalidate 时 ，dbms_stats 包 会 将 所 有 依赖 于 变更 的 统计 信息 的 游标 标 
记 为 延迟 失效 状态 程序 包 会 在 游标 级 别 设置 一 个 时 间 戳 , 指明 这 个 游标 何 时 不 应 该 再 使 用 了 
注意 这 个 时 间 戳 对 于 每 个 游标 都 是 不 同 的 ， 它 基于 一 个 从 游标 被 标记 的 那 一 刻 开始 最 长 五 个 小 
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时 的 随机 值 来 设置 。 真 实 的 失效 动作 是 由 服务 器 进程 来 执行 的 ， 该 进程 尝试 重用 标记 为 延迟 失 
效 的 游标 。 因 此 ， 如 果 一 个 标记 为 延迟 失效 的 游标 从 来 没有 被 重新 解析 过 ， 那 么 它 永 远 不 会 失 
效 。 唯 一 的 例外 是 关联 到 并 行 SQL 语句 的 游标 。 这 样 的 游标 会 通过 dbms_stats 包 立即 失效 。 


8.3.3 备份 表 


用 于 收集 对 象 统计 信息 的 所 有 存储 过 程 都 支持 表 8-2 中 列 出 的 备份 表 参 数 。 这 些 参数 指示 
dbms_stats 包 在 使 用 数据 字典 中 新 的 统计 信息 覆盖 旧 的 统计 信息 之 前 ， 将 现 有 的 统计 信息 备份 到 一 张 
备份 表 中 。 这 些 参 数 如 下 所 示 。 

口 stattab 指 定 在 数据 字典 之 外 的 一 张 备份 表 用 于 存储 统计 信息 。 如 果 指定 了 NULL ( 默认 值 ), 则 

不 会 使 用 备份 表 。 

口 statid 是 一 个 可 选 ID， 用 于 识别 存储 在 stattab 参 数 所 指定 的 备份 表 中 的 多 组 不 同 对 象 统计 信 
息 。 只 有 合法 的 Oracle 标 识 符 " 才 受 支持 。 如 果 指 定 了 NULL ( 默认 值 )， 则 不 会 有 ID 和 对 象 统 计 
信息 关联 。 

口 statown 指 定 由 stattab 参 数 指定 的 表 的 所 有 者 。 默 认 值 是 NULL， 此 时 会 使 用 当前 用 户 作为 所 有 
者 。 

要 创建 备份 表 ， 可 以 使 用 dbms_stats 包 提供 的 create_stat_table 存 储 过 程 。 如 下 例 所 示 ， 创 建 备 

份 表 就 是 指定 所 有 者 〈 使 用 ownname 参 数 ) 和 备份 表 名 称 ( 使 用 stattab 参 数 ) 的 问题 。 此 外 ， 可 选 的 
tblspace 参 数 指 定 将 表 创 建 在 哪个 表 空间 上 。 如 果 tblspace 参 数 没有 指定 ， 默 认 情况 下 ， 备 份 表 最 终 
会 创建 在 用 户 的 默认 表 空间 中 : 

dbms_ stats.create stat table(ownname => user, 


stattab => 'MYSTATS', 
tblspace => 'USERS') 


因为 备份 表 用 来 存储 各 种 不 同 的 信息 ， 它 的 大 部 分 列 是 通用 的 。 举 例 来 说 ， 在 11.2 版 本 中 有 12 个 
列 用 于 存储 数字 值 ( 命名 为 n1...n12 )，5 个 列 用 于 存储 字符 串 值 ( 命名 为 c1...c5 )，2 个 列 用 于 存储 位 
串 值 (命名 为 T1 和 Tr2 )， 还 有 1 个 列 存储 日 期 时 间 值 (命名 为 d1 )。 

请 注意 ,这 么 多 年 以 来 ,备份 表 的 结构 已 经 发 生 了 改变 。 因 此 ， 你 需要 在 升级 到 一 个 新 版 本 的 数 
据 库 后 或 在 不 同 的 数据 库 版 本 之 间 移 动 备 份 表 时 也 升级 你 的 备份 表 。 和 否则 ， 可 能 无 法 使 用 备份 表 。 基 
于 这 个 目的 ， dbms_stats 包 提供 了 upgrade_stat table 存储 过 程 。 要 使 用 它 你 需要 指定 所 有 者 ( 通过 
ownname 参 数 ) 和 备份 表 的 名 称 ( 通过 stattab 参 数 )。 例 如 : 


dbms_stats.upgrade stat table(ownname => user, 
stattab => 'MYSTATS') 


要 删除 备份 表 ， 可 使 用 dbms_stats 包 提供 的 drop_stat_table 存 储 过 程 : 


dbms_stats.drop stat table(ownname => user, 
stattab => 'MYSTATS') 


也 可 以 通过 常规 DROP TABLE 语 句 来 删除 备份 表 。 


中 参考 Oracle 官 方 文档 的 SQL Language Reference 手 册 中 关于 标识 符 的 定义 。 
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8.4 配置 dbms stats 包 


dbms_stats 包 提供 了 两 组 子 程序 ， 用 来 配置 在 之 前 章节 中 描述 的 某 些 参数 的 默认 值 。 第 一 组 仅 应 
在 10.2 版 本 中 使 用 。 实 际 上 ， 第 一 组 子 程序 在 11.1 版 本 中 已 废弃 。 因此 ， 从 11.1 版 本 开始 ， 应 该 使 用 由 
第 二 组 子 程序 提供 的 子 程序 。 


8.4.1 传统 方式 


在 10.2 版 本 中 ， 你 可 以 更 改 cascade 、estimate _ percent 、degree 、method opt 、no_invalidate 和 
granularity 参 数 的 全 局 默认 值 。 这 些 默认 值 能 进行 修改 是 因为 它们 不 是 硬 编码 写 在 存储 过 程 中 的 ， 
而 是 在 运行 时 从 数据 字典 中 抽取 出 来 的 。dbms _stats 包 的 set_param 存 储 过 程 可 以 用 来 设置 默认 值 。 
要 执行 这 个 过 程 ， 需 要 analyze any dictionary 和 analyze any 系 统 权 限 。dbms_stats 包 的 get_param 
消 数 可 以 用 来 获取 默认 值 。 下 面 的 例子 展示 了 如 何 使 用 它们 。 注 意 ，pname 是 参数 的 名 称 ， 而 pval 是 
参数 的 值 : 


SQL> execute dbms output.put line(dbms stats.get param(pname => 'CASCADE')) 


DBMS_STATS.AUTO CASCADE 
SQL> execute dbms stats.set param(pname => 'CASCADE', pval =>'TRUE') 
SQL> execute dbms output.put line(dbms stats.get param(pname => 'CASCADE')) 


TRUE 
另 一 个 可 以 使 用 这 种 方法 设置 的 参数 是 autostats target 。 这 个 参数 的 唯一 用 途 是 ， 
gather_stats_ job 任务 可 以 使 用 该 参数 决定 应 该 处 理 哪些 对 象 的 统计 信息 收集 。 表 8-7 列 出 了 可 选 的 
值 。 其 默认 值 是 auto。 
表 8-7 autostats target 人 参数 接受 的 值 


秆 含 义 
all 处 理 所 有 的 对 象 。 直 到 11.2 版 本 (包括 在 内 ) ， 固 定 表 都 被 排除 在 外 。 但 是 ， 从 12.1 版 本 开始 ， 固 定 表 
都 被 包括 在 内 
auto 由 任务 来 决定 应 该 处 理 哪些 对 象 


oracle 只 有 属于 数据 字典 的 对 象 会 被 处 理 ， 固 定 表 除外 
要 想 无 需 多 次 执行 get_param 函 数 就 获取 所 有 参数 的 默认 值 ， 可 以 使 用 以 下 查询 ”: 


SQL> SELECT sname AS parameter, nvl(spare4,sval1) AS default value 
2 FROM sys.optstat hist control$ 
3 WHERE sname IN ('CASCADE','ESTIMATE PERCENT','DEGREE','METHOD OPT', 
4 "NO_INVALIDATE','GRANULARITY" , 'AUTOSTATS TARGET' ); 


PARAMETER DEFAULT VALUE 


GD 遗憾 的 是 ，Oracle 并 不 会 通过 一 张 数据 字典 视图 显示 这 个 信息 ， 也 就 是 说 这 个 查询 是 基于 内 部 表 的 。 访 问 这 张 表 
需要 select any dictionary 系 统 权限 。 
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CASCADE DBMS_STATS.AUTO_CASCADE 
ESTIMATE_PERCENT DBMS_STATS.AUTO_SAMPLE_SIZE 
DEGREE NULL 

METHOD_OPT FOR ALL COLUMNS SIZE AUTO 
NO_INVALIDATE ~ DBMS_ STATS.AUTO INVALIDATE 
GRANULARITY AUTO 


AUTOSTATS_TARGET AUTO 


要 还 原 原 来 设置 的 默认 值 ， 可 以 使 用 dbms_stats 包 提供 的 reset_param_defaults 存 储 过 程 。 


8.4.2 ”现代 方式 


自 11.1 版 本 开始 ， 为 参数 设置 默认 值 的 概念 ， 被 称 作 首 选项 ， 与 10.2 版 本 相 比 ， 该 功能 有 了 极 大 
的 增强 。 实 际 上 ， 你 不 仅 可 以 设置 全 局 默认 值 ， 也 可 以 在 表 级 别 设置 默认 值 。 这 些 增强 的 一 个 结果 就 
是 上 一 节 中 描述 的 get_param 函 数 、set_param 过 程 和 reset_param_defaults 过 程 都 被 淘汰 了 。 

可 以 为 参数 autostats target、cascade、concurrent、estimate percent、degree、method opt、 
no_invalidate、granularity、publish 、incremental 、stale_percent 、table_cached blocks( 从 11.2.0.4 
版 本 开始 ) 以 及 从 12.1 版 本 开始 出 现 的 参数 global temp table stats 、incremental_staleness 和 
incremental_level 等 设置 默认 值 。 要 修改 它们 ， 本 以 使 用 dbms_stats 包 提供 的 以 下 存储 过 程 。 

口 set_global_prefs 设 置 全 局 首选 项 。 它 取代 了 set_param 存 储 过 程 。 

口 set_database_prefs 设 置 数据 库 级 首选 项 。 全 局 首选 项 和 数据 库 级 别 首选 项 的 区 别 是 后 者 不 用 

作 数据 字 典 对 象 。 换 句 话说 ， 数 据 库 级 别 首选 项 只 作用 于 用 户 定 义 的 对 象 。 

口 set_schema_prefs 为 某 个 特定 的 模式 设置 首选 项 。 

口 set table_prefs 为 某 个 特定 表 设置 首选 项 。 

注意 参数 autostats_target 和 concurrent 只 能 通过 set_global_prefs 存 储 过 程 来 修改 。 


警告 ”存储 过 程 set_database prefs 和 set schema_prefs 不 会 直接 将 首选 项 信息 存储 到 数据 字典 中 ， 
而 是 会 将 它们 转变 成 为 调用 存储 过 程 时 即刻 在 数据 库 中 或 模式 中 可 用 的 所 有 对 象 的 表 级 别 首 
选项 , 换 句 话说 , 真正 存在 的 只 有 全 局 首选 项 或 者 表 级 别 首选 项 ,存储 过 程 set_database_prefs 
和 set schema prefs 只 是 对 存储 过 程 set table prefs 的 简单 包装 ,。 这 意味 着 对 于 调用 完 这 两 个 
存储 过 程 后 创建 的 新 表 ， 将 会 使 用 全 局 首选 项 


下 面 的 PL/SQL 代 码 块 展示 了 如 何 为 cascade 参 数 设置 不 同 的 值 。 注 意 ，pname 指 参数 名 称 ，pvalue 
指 参 数值 ，ownname 指 所 有 者 ， 而 tabname 指 表 名 。 再 强调 一 次 ， 要 非常 小 心 ， 因 为 在 这 样 的 PL/SQL 代 
码 块 中 调用 的 顺序 十 分 关键 。 实 际 上 ， 每 一 次 调用 都 会 覆盖 上 一 次 调用 完成 的 一 些 定义 : 


BEGIN 
dbms_stats.set database prefs(pname -=> 'CASCADE', 
pvalue => "DBMS STATS.AUTO CASCADE'); 
dbms_stats.set schema prefs(ownname => 'SCOTT', 
pname => 'CASCADE', 
pvalue => 'FALSE'); 
dbms_stats.set table prefs(ownname => "SCOTT ， 


220 第 8 章 ”对 象 统计 信息 


tabname => “EMP '， 

pname => 'CASCADE', 

pvalue => 'TRUE'); 
END; 


为 获取 当前 的 设置 ， 可 以 使 用 get_prefs 函 数 来 取代 get_param 函 数 。 下 面 的 查询 用 来 展示 在 上 面 
的 PL/SQL 块 中 所 执行 设置 的 效果 。 注意 , pname 是 参数 名 称 , ownname 是 所 有 者 名 称 , 而 tabname 是 表 名 。 
正如 你 所 看 到 的 ,依赖 于 所 指定 的 参数 ,该 函数 会 返回 指定 级 别 的 值 。 这 次 对 于 首选 项 的 搜索 按照 图 
8-9 所 示 的 方式 进行 : 


SQL> SELECT dbms stats.get prefs(pname => 'cascade') AS global, 
2 dbms stats.get prefs(pname => 'cascade', 

3 ownname => 'SCOTT', 

4 tabname =>"'DEPT') AS dept, 

5 dbms stats.get prefs(pname => 'cascade', 

6 ownname => 'SCOTT', 

7 tabname =>'EMP') AS emp 

8 FROM dual; 


GLOBAL DEPT EMP 


使 用 全 局 首选 项 


图 8-9 在 搜索 首选 项 时 ， 表 级 别 设置 优先 于 全 局 设置 


如 果 和 希望 不 用 多 次 执行 get_param 函 数 就 可 以 获取 多 个 全 局 首选 项 , 正如 上 一 节 中 描述 的 那样 , 可 
以 查询 内 部 数据 字典 表 optstat_hist_control$。 要 获取 表 的 首选 项 , 也 可 以 执行 接 下 来 的 查询 。 注意 ， 
即便 之 前 的 PL/SQL 代 码 块 配 置 是 在 模式 级 别 ，dba_tab_stat_prefs 视 图 仍 显示 了 其 设置 结果 : 
SQL> SELECT table name, preference name, preference value 
2 FROM dba tab stat prefs 
WHERE owner = 'SCOTT' 


凶 
4 AND table name IN ('EMP', 'DEPT') 
5 ORDER BY table name, preference name; 


TABLE NAME PREFERENCE NAME PREFERENCE VALUE 


DEPT CASCADE FALSE 
EMP CASCADE TRUE 


要 删除 首选 项 ，dbms_stats 包 提供 了 以 下 存储 过 程 。 
口 reset global pref_defaults 将 全 局 首选 项 重 置 为 默认 值 。 
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口 delete database_prefs 在 数据 库 级 别 删除 首选 项 配置 。 

口 delete_schema_prefs 在 模式 级 别 删 除 首 选项 配置 。 

口 delete table_prefs 在 表 级 别 删除 首选 项 配置 。 

下 面 的 调用 展示 了 如 何 删 除 当前 scott 用 户 下 包含 的 所 有 表 中 与 cascade 参 数 相 关 的 首选 项 : 

dbms_stats.delete schema prefs(ownname => 'SCOTT', pname => 'CASCADE') 

要 在 全 局 级 别 和 数据 库 级 别 执行 这 些 存 储 过 程 ， 需 要 有 analyze any dictionary 和 analyze any 系 
统 权 限 。 要 在 模式 级 别 或 表 级 别 执行 这 些 存储 过 程 , 需要 以 所 有 者 身份 连接 到 数据 库 或 者 拥有 analyze 
any 系 统 权限 。 


8.5 处理 全 局 临时 表 


直到 11.2 版 本 为 止 (包括 11.2 版 本 在 内 )， 对 于 全 局 临时 表 ，dbms_stats 包 仅 对 gather database _ 
stats 和 gather_ schema_stats 存 储 过 程 提 供 gather_temp 人 参数 的 支持 。 通 过 这 个 参数 ， 仅 能 够 控制 是 否 
处 理 全 局 临时 表 。 收 集 的 执行 过 程 与 “普通 ” 表 没 有 区 别 。 结 果 ， 在 大 多 数 时 间 里 ， 抛 开 对 象 统计 信 
息 是 如 何 被 收集 的 不 说 , 全 局 临时 表 上 没有 可 以 使 用 的 对 象 统计 信息 。 原 因 有 两 个 。 第 一 , dbms_stats 
在 处 理 过 程 开始 会 执行 一 个 COMMIT 操 作 ， 因 此 ， 通过 on commit delete rows (也 就 是 默认 选项 ) 选项 
创建 的 临时 表 永 远 是 空 的 。 第 二 ， 如 果 收 集 过 程 与 往常 一 样 ， 发 生 在 一 个 像 默 认 收集 任务 这 样 的 任务 
中 ,全 局 临时 表 也 是 空 的 。 总 之 ， 获 取 有 意义 的 对 象 统计 信息 的 唯一 方式 就 是 手工 设置 它们 。 但 是 ， 
即使 你 手工 设置 了 它们 ， 也 没有 办 法 找到 一 组 适合 所 有 人 的 对 象 统计 信息 。 实 际 上 ， 每 个 会 话 都 有 可 
能 在 这 些 表 中 存储 一 组 不 同 数量 的 数据 。 

最 终 , 12.1 版 本 引入 了 一 个 新 特性 来 正确 地 处 理 全 局 临时 表 - 其 思路 是 你 可 以 在 共享 统计 信息 ( 在 
11.2 及 之 前 的 版 本 中 唯一 可 用 的 选项 ) 和 会 话 统计 信息 之 间 进 行 选 择 。 如 果 使 用 了 会 话 统计 信息 ( 全 
局 临时 表 的 默认 选项 )， 每 个 会 话 都 可 以 单独 收集 一 组 对 其 他 会 话 并 不 可 见 的 对 象 统计 信息 。 收 集 的 
过 程 本 身 与 往常 一 样 , 通过 dbms_stats 包 的 gather table _stats 存 储 过 程 来 执行 。 这 意味 着 要 想 从 这 个 
特性 中 获 益 , 应 用 程序 必须 进行 修改 , 以 在 全 局 临时 表 数 据 加 载 完毕 后 立刻 执行 对 gather_table_stats 
过 程 的 调用 。 注 意 ， 为 了 使 这 个 特性 发 挥 作用 ，dbms_stats 包 处 理 流程 开始 的 COMMIT 操 作 被 移 除了 。 
下 面 的 例子 (来自 于 gtt.sql 脚 本 ) 说 明了 这 个 特性 是 如 何 运 作 的 : 

SQL> CREATE GLOBAL TEMPORARY TABLE t (id NUMBER, pad VARCHAR2(1000)); 

SOL> INSERT INTO 七 SELECT rownum, rpad('*",1000,'*') FROM dual CONNECT BY level <= 1000; 

SQOL> execute dbms stats.gather table stats(ownname => user, tabname => 't') 

SOL> SELECT num rows, blocks, avg row len, scope 

2 FROM user tab statistics 
3 WHERE table name = 'T'; 
NUM ROWS BLOCKS AVG ROW LEN SCOPE 


SHARED 
1000 147 1005 SESSION 


SQL> SELECT count(*) 
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2 FROMt 
3 WHERE id BETWEEN 10 AND 100; 


COUNT(*) 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | | | 42 (100)| | 
| 1 | SORT AGGREGATE | | 型 中 4 | | 
|* 2 | TABLE ACCESS FULL| T | 92 | 368 | 42 (0)| 00:00:01 | 


- Global temporary table session private statistics used 
要 控制 是 使 用 共享 统计 信息 还 是 使 用 会 话 统计 信息 ， 可 以 设置 global temp_table stats 首 选项 , 
受 支持 的 值 有 两 个 : shared 和 session。 默 认 值 是 session。 


8.6 ”处 理 挂 起 的 对 象 统计 信息 


通常 ， 一 旦 收集 过 程 结束 ， 就 会 将 对 象 统计 信息 发 布 到 查询 优化 器 ( 也 就 是 说 ,使 其 可 访问 )。 
这 意味 着 无 法 在 不 覆盖 当前 对 象 统计 信息 的 情况 下 ( 例如， 基于 测试 目的 ) 收集 统计 信息 。 当 然 了 ， 
用 于 测试 用 途 的 应 该 是 测试 数据 库 , 但 有 时 候 测 试 环 境 并 不 总 是 那么 理想 ; 你 可 能 想 在 生产 环境 中 做 
这 样 的 测试 。 测 试 数据 库 中 存储 的 数据 与 生产 数据 库 中 存储 的 数据 不 一 致 ， 就 是 这 样 的 一 个 例子 。 

自 11.1 版 本 起 ， 就 可 以 将 收集 统计 信息 与 发 布 它们 的 过 程 分 隔 开 来 ， 这 样 便 可 以 使 用 未 发 布 的 对 
象 统计 信息 ， 也 就 是 所 说 的 挂 起 的 统计 信息 ( pending statistics )， 将 其 用 作 测 试用 途 。 下 面 是 处 理 过 
程 (完整 的 例子 在 pending object statistics.sql 脚 本 中 提供 )。 

(1) 通过 将 publish 首 选项 设置 为 FALSE 来 禁用 自动 发 布 ( 默认 值 是 TRUE )。 正 如 上 一 节 所 描述 的 ， 
你 可 以 通过 全 局 、 数 据 库 、 模 式 或 者 表 级 别 来 完成 设置 。 下 面 的 例子 展示 了 如 何 为 属于 当前 用 户 的 一 
张 表 设置 该 首选 项 : 

dbms_stats.set table prefs(ownname => user, 

tabname => 'T', 


pname => 'PUBLISH', 
pvalue => 'FALSE') 


(2) 收集 对 象 统计 信息 。 因 为 这 张 表 的 publish 首 选项 被 设置 成 FALSE， 最近 收集 的 对 象 统计 信息 没 
有 被 发 布 ， 而 是 创建 了 一 组 挂 起 的 统计 信息 。 这 意味 着 查询 优化 器 仍然 使 用 此 次 收集 之 前 可 用 的 统计 
信息 。 同 时 ,依赖 于 这 张 表 的 游标 并 没有 失效 : 
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dbms_stats.gather table stats(ownname => user, tabname => 'T') 

(3) 要 测试 挂 起 的 统计 信息 对 一 个 应 用 程序 或 者 一 组 SQL 语 句 的 影响 , 既 可 以 通过 在 会 话 级 别 将 初 
始 化 参数 optimizer use pending statistics 设 置 为 TRUE ， 也 可 以 通过 在 SQL 语句 级 别 使 用 
opt_param('optimizer use pending statistics' 'true') 这 个 hint。 

(4) 如 果 测 试 成 功 ， 可 以 通过 调用 publish pending_ stats 存储 过 程 来 发 布 挂 起 的 统计 信息 ( 换 句 
话说 ,使 其 对 所 有 会 话 可 用 )。 下 面 的 例子 会 展示 如 何 为 单 张 表 发 布 挂 起 的 统计 信息 。 如 果 将 tabname 
参数 设置 为 NLL， 指 定 模式 下 所 有 挂 起 的 统计 信息 都 将 被 发 布 。 这 个 过 程 还 有 两 个 额外 的 参数 。 如 前 
所 述 ， 第 三 个 参数 no_invalidate 控 制 依赖 于 修改 的 对 象 统计 信息 的 游标 是 否 失效 。 第 四 个 参数 force 
用 于 解 开 对 和 象 统计 信息 上 潜在 的 锁 ( 详 见 8.10 节 )。 其 默认 值 为 FALSE， 意思 是 对 锁 的 处 理 遵守 默认 值 : 

dbms_stats;publish pending stats(ownname => user, tabname => 'T') 

(5) 如 果 测 试 不 成 功 ， 可 以 通过 调用 delete_pending_stats 存 储 过 程 删 除 挂 起 的 统计 信息 。 如 果 没 
有 指定 tabname 参 数 的 值 或 将 其 设置 为 NULL， 通 过 ownname 参 数 指定 的 整个 模式 下 挂 起 的 统计 信息 都 会 
被 删除 : 


dbms_stats.delete pending stats(ownname => user, tabname => 'T') 
(6) 通过 将 publish 首 选项 设置 为 TRUE 来 启用 自动 发 布 。 需 要 执行 这 一 步 来 恢复 第 1 步 中 执行 的 更 改 : 


dbms_stats.set table prefs(ownname => user, 
tabname => 'T', 
pname => 'PUBLISH', 
pvalue => 'TRUE') 


要 执行 存储 过 程 publish pending stats 和 delete pending stats， 需 要 以 所 有 者 身份 连接 或 者 具 
有 analyze any 系 统 权 限 。 

如 果 你 有 兴趣 了 解 这 些 挂 起 的 统计 信息 的 值 ， 下 面 的 数据 字典 视图 提供 了 所 有 必要 的 信息 。 对 于 
每 个 视图 ， 都 有 dba、all， 以 及 在 12.1 多 租户 环境 下 的 cdb 版 本 。 

口 user tab pending_stats 显 示 挂 起 的 表 统计 信息 。 

DO user ind_ pending_stats 显 示 挂 起 的 索引 统计 信息 。 

口 user col pending_stats 显 示 挂 起 的 列 统计 信息 。 

口 user tab histgrm pending stats 显 示 挂 起 的 直方 图 。 

这 些 数据 字典 视图 的 结构 分 别 类 似 于 user tab statistics、 user ind statistics、 user tab col 
statistics 以 及 user tab histograms。 
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为 分 区 的 表 和 索引 收集 对 象 统计 信息 是 很 有 挑战 性 的 。 本 节 将 具体 描述 这 些 挑战 ， 并 介绍 两 种 应 
对 这 些 挑战 的 技术 。 


8.7.1 挑战 


dbms_stats 包 使 用 两 种 主要 的 方式 为 分 区 的 表 和 索引 收集 对 象 统计 信息 。 
口 在 对 象 、 分 区 以 及 子 分 区 级 别 上 通过 在 每 个 级 别 上 分 别 执行 的 查询 来 收集 对 象 统计 信息 。 
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口 只 在 物理 层面 ( 可 能 是 分 区 级 别 也 可 能 是 子 分 区 级 别 ) 收集 对 象 统计 信息 ， 并 使 用 其 结果 来 
推算 出 其 他 级 别 的 对 象 统计 信息 。 
下 面 是 这 两 种 方式 的 两 个 关键 区 别 。 
口 总 的 来 说 ， 第 一 种 收集 对 象 统计 信息 的 方式 需要 的 时 间 和 资源 要 高 很 多 。 实 际 上 ， 在 表 /索引 
级 别 收集 对 象 统 计 信 息 时 ， 必 须要 访问 所 有 的 段 。 同 样 的 事情 也 会 发 生 在 子 分 区 对 象 的 分 区 
级 别 。 例 如 ， 一 张 包含 多 年 数据 的 按 星 期 分 区 的 表 。 如 果 一 个 分 区 发 生 了 变化 ,那么 必须 访 
问 所 有 分 区 才能 更 新 表 / 索 引 级 别 统计 信息 。 甚 至 在 只 有 一 个 分 区 的 数据 被 修改 了 的 情况 下 ， 
也 必须 访问 所 有 分 区 。 
口 第 二 种 方式 消耗 的 资源 则 要 少 很 多 , 但 是 这 种 方式 只 能 在 物理 级 别 生 成 准确 的 统计 信息 。 这 
是 因为 它 无 法 从 底层 的 分 区 和 子 分 区 推算 出 不 重复 值 的 数量 和 直方 图 。 顺 便 说 一 下 ， 其 他 所 
有 的 统计 信息 都 可 以 推算 出 来 。 
通过 第 一 种 方式 收集 的 对 象 统计 信息 叫 作 全 局 统计 信息 。 通过 第 二 种 方式 收集 的 统计 信息 叫 作 推 
算 统计 信息 (有 时 也 称 作 聚 合 统计 信息 )。 要 辨别 收集 的 是 哪 种 类 型 ， 可 以 检查 表 8-2 中 列举 的 数据 字 
典 视 图 中 global _stats 列 值 是 YES$ 还 是 NO。 只 要 可 能 , dbms_stats 包 就 会 收集 全 局 统计 信息 。dbms_stats 
包 只 会 在 某 些 情况 下 收集 推算 统计 信息 , 例如， 收集 的 粒度 被 明确 地 限制 在 子 分 区 级 别 并 且 在 分 区 以 
及 表 / 索 引 级 别 没有 可 用 的 对 象 统计 信息 时 。 
接 下 来 的 例子 基于 脚本 global_stats.sql 生 成 的 输出 ， 展 示 了 这 样 的 案例 : 对 于 一 张 按 范围 分 区 
并 按照 hash 进 行 子 分 区 的 表 ， 其 推算 统计 信息 并 不 准确 。 注 意 ， 不仅 表 和 分 区 级 别 的 不 重复 值 数量 有 
误 ，global_stats 列 也 被 设置 为 NO。 
口 在 一 张 没有 对 象 统计 信息 的 表 上 执行 子 分 区 级 别 的 收集 ( 注意 ， 没 有 涉及 采样 ): 
SOL> BEGIN 


2 dbms_stats.delete table stats(ownname => user, 

3 tabname => 't'); 

4 dbms_stats.gather table_ stats(ownname = USer; 

5 tabname Ee 

6 estimate percent => 100， 

6 granularity => "subpartition'); 
7 END; 

8 / 


口 在 表 级 别 的 不 重复 值 数量 是 错 的 ， 因 为 它们 是 通过 推算 统计 信息 收集 的 : 


SQL> SELECT count(DISTINCT sp) 
2 FROM t; 


COUNT(DISTINCTSP) 


SOL> 
SQL> SELECT num distinct, global stats 
2 FROM user tab col statistics 
3 WHERE table name = "T' 
4 AND column name = 'SP'; 


NUM_DISTINCT GLOBAL STATS 


口 在 分 区 级 别 ( 这 里 指 一 个 单独 的 分 区 ) 的 不 重复 值 数量 也 是 错 的 ， 因 为 它们 是 通过 推算 统计 


言 息 收集 的 : 


SQL SELECT count(DISTINCT sp) 
2 FROM t PARTITION (q1); 


COUNT(DISTINCTSP) 


SOL> 
SQL> SELECT num distinct, global stats 
2 FROM user part col statistics 
3 WHERE table name = "T' 
4 AND partition name = "01° 
5 AND column name = 'SP'; 


NUM_DISTINCT GLOBAL STATS 


zz 


8.7” 处理 分 区 对 象 


口 在 子 分 区 级 别 ( 这 里 是 对 于 单个 分 区 来 说 的 ) 的 不 重复 值 数量 是 正确 的 : 
SQL> SELECT 'Q1 SP1' AS part name, count(DISTINCT sp) FROM t SUBPARTITION (q1_sp1) 


UNION ALL 


TD 


SELECT "01 SP2', count(DISTINCT sp) FROM t SUBPARTITION (q1_sp2) 


UNION ALL 


UNION ALL 


3 
4 
5 SELECT 'Q1 Sp3', count(DISTINCT sp) FROM t SUBPARTITION (q1 sp3) 
6 
7 


SELECT 'Q1 SP4', count(DISTINCT sp) FROM t SUBPARTITION (q1 sp4); 


PART NAME COUNT(DISTINCTSP) 


Q1 SP1 20 
01 SP2 28 
01 SP3 25 
Q1 SP4 27 


SQL> SELECT subpartition name, num distinct, global stats 
2 FROM user subpart col statistics 
3 WHERE table name = 'T' 
4 AND column name = 'SP" 
5” AND subpartition name LIKE 'Q1%'; 


SUBPARTITION NAME NUM DISTINCT GLOBAL STATS 


0Q1 SP1 20 YES 
Q1_SP2 28 YES 
Q1 SP3 25 YES 
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警告 表 /分 区 级 别 的 对 象 统计 信息 ， 只 有 当 底 层 的 所 有 分 区 都 有 合适 的 对 象 统计 信息 时 ， 才 可 以 从 
底层 的 分 区 推算 出 来 。 这 也 适用 于 从 子 分 区 统计 信息 推算 分 区 统计 信息 。 此 外 ， 要 知道 
dbms_stats 包 不 会 使 用 推算 统计 信息 替代 全 局 统计 信息 。 两 种 情形 都 可 以 通过 脚本 
global_stats.sql 重 现 出 来 。 


概括 起 来 ， 全 局 统计 信息 要 比 推算 统计 信息 更 加 精确 ， 但 是 需要 更 多 的 时 间 和 资源 来 进行 收集 。 
有 时 候 可 能 推算 统计 信息 就 足够 了 。 因 此 在 实践 中 ， 对 于 大 表 来 说 ， 在 准确 度 与 达到 目的 所 需 的 时 间 
和 资源 之 间 找 到 均衡 点 很 重要 。 基 于 这 个 原因 ， 接 下 来 的 两 节 将 描述 可 以 用 来 管理 足够 大 的 表 的 对 象 
统计 信息 的 技术 ， 进 而 防止 重复 收集 完全 的 全 局 统计 信息 。 


8.7.2 ” 增 量 统计 信息 


正如 上 一 节 中 描述 的 那样 ， 收 集 全 局 统计 信息 有 优点 也 有 缺点 。 主 要 的 优点 体现 在 表 级 别 的 对 象 
统计 信息 的 准确 性 上 ， 如 果 使 用 了 子 分 区 ,这 个 优点 同样 体现 在 分 区 级 别 。 主 要 的 缺点 体现 在 收集 它 
们 所 需要 的 资源 和 时 间 上 。 

增 量 统计 信息 的 目标 是 在 降低 收集 对 象 统计 信息 所 需 时 间 和 资源 的 前 提 下 提供 相同 的 准确 性 。 这 
怎么 可 能 呢 ? 其 关键 思路 是 在 分 区 级 别 收集 对 象 统计 信息 期 间 ， 利 用 存储 在 数据 字典 中 的 额外 信息 
( 称 作 概 要 信息 )， 在 表 级 别 精确 地 推算 对 象 统计 信息 。 

要 想 从 增 量 统计 信息 中 获 益 必 须 首先 满足 以 下 要 求 。 

口 正在 运行 的 是 11.1 或 之 后 的 版 本 。 

口 对 于 正在 处 理 的 表 ， 其 incremental 首 选项 设置 为 TRUE ( 默认 值 是 FALSE ): 


dbms_stats.set table prefs(ownname => user, 
tabname => 't', 
pname => 'incremental', 
pvalue => 'TRUE'); 


口 对 于 正在 处 理 的 表 ， 其 publish 首 选项 设置 为 TRUE ( 默认 值 )。 

口 对 于 正在 处 理 的 表 ， 将 参数 estimate_percent 设 置 为 dbms_stats.auto sample size ( 默认 值 ) 

口 在 sysaux 表 空间 中 有 可 用 剩余 空间 。 

收集 过 程 本 身 还 是 按照 通常 的 方式 进行 , 例如 , 通过 对 dbms_stats 包 的 gather_table stats 存储 过 
程 的 调用 。 唯 一 需要 小 心 应 对 的 是 ， 要 利用 增 量 统计 信息 ， 必 须 在 分 区 级 别 呈 现 概要 信息 。 因 此 ，, 设 
置 完 incremental 首 选项 后 , 你 必须 在 所 有 分 区 上 收集 新 的 对 象 统计 信息 。 你 可 以 认为 在 所 有 分 区 上 收 
集 新 的 对 象 统计 信息 的 操作 是 最 终 启 用 增 量 统计 信息 的 那个 操作 。 也 就 是 说 ， 只 满足 上 面 列 举 的 要 求 
是 不 够 的 。 

一 旦 所 有 的 概要 信息 都 就 位 了 ，dbms_stats 包 就 会 使 用 其 监测 信息 来 了 解 哪个 分 区 ( 或 子 分 区 ) 
被 修改 了 ， 从 而 需要 新 的 对 象 统计 信息 。 因 此 ， 当 使 用 增 量 统计 信息 时 ， 不 应 该 去 瞄准 被 修改 的 分 区 
(或 子 分 区 )， 而 是 应 该 让 dbms stats 包 自己 找 出 它 需 要 做 的 事情 。 下 面 的 例子 基于 脚本 
incremental_stats.sql, 就 验证 了 这 一 点 (仔细 看 一 下 last_analyzed 时 间 玲 来 确定 在 哪些 对 象 上 收集 
了 统计 信息 ): 


8.7 处 理 分 区 对 象 


SQL> SELECT object type || ' " || nvl(subpartition name, partition name) AS object, 


[ed 


object type, num rows, blocks, avg row_ len, 


3 to_char(last analyzed, 'HH24:MI:SS') AS last analyzed 

4 FROM user tab statistics 

5 WHERE table name = “T" 

6 ORDER BY partition name, subpartition name; 
0BJECT OBJECT TYPE NUM ROWS BLOCKS AVG ROW LEN LAST_ANALYZED 
SUBPARTITION Q1 SP1 SUBPARTITION 1786 46 i116 14:52:22 
SUBPARTITION Q1 SP2 SUBPARTITION 2473 46 116 14:52:22 
PARTITION Q1 PARTITION 3959 92 116 14155222 
SUBPARTITION Q2_SP1 SUBPARTITION 1804 46 Te .22 
SUBPARTITION 0Q2 SP2 SUBPARTITION 2200 46 146 14:52:22 
PARTITION Q2 PARTITION 4004 92 116 14:52:22 
SUBPARTITION Q3_SP1 SUBPARTITION 1815 46 116 14:52:22 
SUBPARTITION 0Q3 SP2 SUBPARTITION 2233 46 116 14:52:22 
PARTITION 03 PARTITION 4048 92 116 14:52:22 
SUBPARTITION 0Q4_SP1 SUBPARTITION 1795 46 146 T4152;22 
SUBPARTITION Q4 SP2 SUBPARTITION 2194 46 116 14;52:22 
PARTITION 04 PARTITION 3989 92 116 14:52:22 
TABLE TABLE 16000 368 117 14252222 


SQL> INSERT INTO t SELECT * FROM 七 SUBPARTITION (q1_sp1); 


SOL> execute dbms stats.gather table stats(ownname => user, tabname 


=> 't', granularity=>"'all') 


SQL> SELECT object type || ' ' || nvl(subpartition name, partition name) AS object, 
2 object type, num rows, blocks, avg row_ len, 
to char(last analyzed, 'HH24:MI:SS') AS last analyzed 


WHERE table name = 'T' 


3 
4 FROM user tab statistics 
EE 
6 


ORDER BY partition name, subpartition name; 


OBJECT OBJECT_TYPE NUM ROWS BLOCKS AVG ROW LEN LAST ANALYZED 
SUBPARTITION Q1 SP1 SUBPARTITION 3572 110 116 14:54:39 
SUBPARTITION Q1_SP2 SUBPARTITION 2173 46 116 14:52:22 
PARTITION 01 PARTITION 5745 156 116 14:54:40 
SUBPARTITION Q2_SP1 SUBPARTITION 1804 46 116 52522 
SUBPARTITION 02 SP2 SUBPARTITION 2200 46 116 14:52:22 
PARTITION 02 PARTITION 4004 92 116 14:52:22 
SUBPARTITION 03_SP1 SUBPARTITION 1815 46 116 和 5523522 
SUBPARTITION Q3_ SP2 SUBPARTITION 2233 46 116 14:52:22 
PARTITION 03 PARTITION 4048 92 116 14:52:22 
SUBPARTITION 04 SP1 SUBPARTITION 1795 46 1146 14:52°22 
SUBPARTITION O04 SP2 SUBPARTITION 2194 46 116 14:52:22 
PARTITION 04 PARTITION 3989 92 116. L452322 
TABLE TABLE 17786 432 117 14:54:40 
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如 本 例 所 示 ， 与 分 区 (或 子 分 区 ) 关联 的 对 象 统计 信息 在 经 历任 何 修 改 后 都 会 被 视 为 陈旧 的 。 从 
12.1 版 本 开始 ， 有 一 个 首选 项 incremental staleness, 你 可 以 通过 它 控制 这 种 行为 。 通 过 默认 值 NULL， 
这 种 行为 与 之 前 的 版 本 表现 一 致 ( 任何 修改 都 会 使 一 个 分 区 变 陈旧 )。 如 果 将 值 设 置 为 
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Use_stale_percent， 只 有 当 修 改 的 数量 超过 通过 stale_percent 首 选项 设置 的 靖 值 后 ,与 分 区 ( 或 子 分 
区 ) 关联 的 对 象 统计 信息 才 会 被 认为 是 陈旧 的 。 此 外 ,通过 值 use_ locked_ stats， 可 以 规定 与 拥有 锁 
定 的 统计 信息 的 分 区 ( 或 子 分 区 ) 关 联 的 对 象 统计 信息 永 不 过 期 ,注意 可 以 同时 启用 use_stale_percent 
和 use_locked_stats。 下 面 是 一 个 例子 : 


dbms_stats.set table prefs(ownname => user, 
tabname => 七， 
pname => 'incremental staleness', 
pvalue => 'use stale percent, use locked stats'); 


仅 在 12.1 版 本 中 ，dbms stats 包 可 以 在 非 分 区 表 上 创建 概要 信息 (为 此 ， 必 须 在 表 上 设置 
nincremental leveln 首 选项 )。 结 果 ， 仅 在 12.1 版 本 中 ， 分 区 交换 才 可 以 利用 增 量 统计 信息 。 


提示 Oracle Support 文 档 How To Collect Statistics On Partitioned Table in 10g and 11g (1417133.1 ) 中 
提供 了 一 个 与 增 量 统计 信息 有 关 的 最 重要 的 Bug 和 补丁 列表 。 查看 这 篇 文章 来 了 解 你 正在 运行 
的 版 本 是 否 需 要 特别 的 关注 ， 并 进一步 检查 第 一 篇 文章 引用 的 其 他 文章 。 


8.7.3 复制 统计 信息 


如 果 频 繁 地 添加 分 区 ， 并 且 它 们 的 内 容 会 随 着 时 间 发 生 显 著 的 变化 ,在 这 样 的 情形 中 ， 保 持 一 组 
有 代表 性 的 分 区 级 别 统计 信息 需要 非常 频繁 的 收集 操作 。 这 些 频繁 的 收集 操作 代表 着 在 资源 使 用 方面 
的 显著 负载 。 此 外 ,通常 情况 下 ， 对 最 近 添加 的 一 个 没有 对 象 统计 信息 的 分 区 不 管 不 顾 可 不 太 好 。 这 
样 做 会 导致 动态 采样 的 发 生 ， 这 是 第 9 章 的 一 个 特性 。 为 了 应 对 这 样 的 问题 ，dbms_stats 包 通过 
copy_table_stats 存 储 过 程 ， 提 供 从 一 个 分 区 或 子 分 区 向 另 一 个 分 区 或 子 分 区 复制 对 象 统计 信息 的 功 
能 。 注 意 复制 过 程 会 像 处 理子 分 区 和 本 地 索引 那样 处 理 列 统计 信息 和 依赖 的 对 象 。 

下 面 的 命令 演示 了 如 何 执行 一 个 复制 过 程 ( 完整 案例 见 脚 本 copy_table_stats.sql )。ownname 和 
tabname 参 数 指定 命令 是 在 哪 张 表 上 执行 。srcpartname 和 dstpartname 参 数 分 别 指定 源 和 目标 分 区 (或 
子 分 区 ): - 


dbms stats.copy _ table stats(ownname => User, 
tabname a "3 
srcpartname => 'p 2014 q1', 
dstpartname => 'p 2015 q1', 
scale factor => 1); 


有 必要 指出 的 是 ，copy_table_stats 存 储 过 程 并 非 简单 地 执行 一 对 一 的 复制 。 相 反 ， 它 能 够 根据 
分 区 定义 的 方式 来 改变 最 大 值 和 最 小 值 。 例 如 ， 对 于 一 张 给 定 的 范围 分 区 表 ， 程 序 dbms_stats 包 能 够 
从 目标 分 区 与 之 前 分 区 的 分 区 边界 推算 出 其 最 小 值 和 最 大 值 。 此 外 ， 自 10.2.0.5 版 本 开始 ,可 以 通过 将 
scale _ factor 参数 设置 为 1 以 外 的 值 来 按 比 例 放大 或 缩小 记录 数 和 数据 块 数 。 

如 果 在 执行 复制 的 表 上 已 经 推算 出 表 / 索 引 级 别 的 统计 信息 ， 那么 在 复制 过 程 中 表 / 索 引 级 别 的 统 
计 信 息 也 会 被 修订 。 举 例 来 说 ， 记 录 数 量 增 加 了 ， 也 会 相应 地 设置 最 大 值 。 在 子 分 区 之 间 复 制 统计 信 
息 时 ， 类 似 的 事情 也 会 发 生 在 分 区 级 别 。 
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提示 “直到 11.2.0.3 的 所 有 版 本 都 在 copy_table _stats 存 储 过 程 中 包含 一 些 bug。 其 中 一 些 bug 是 你 可 能 
永远 都 不 会 遇 到 的 稀有 案例 ， 但 是 另外 的 一 些 bug， 根 据 你 所 运行 的 版 本 ， 可 能 会 影响 核心 功 
能 。 在 Oracle Support 网 站 上 搜索 copy table stats 来 了 解 你 正在 使 用 的 版 本 是 否 有 需要 特别 注意 


8.8 调度 对 象 统计 信息 的 收集 


查询 优化 器 需要 对 象 统计 信息 来 正确 地 完成 它 的 使 命 。 ， 创 建新 的 数据 库 后 ， 会 默认 设置 一 
个 调用 dbms_stats 包 的 gather database stats job Wp tes 作业 。gather database_ 
stats job_ proc 存储 过 程 执行 的 操作 与 调用 dbms_stats 包 的 gather database_stats 存 储 过 程 时 使 用 选 
项 参数 gather_stale 和 gather_empty 执 行 的 操作 在 本 质 上 是 相同 的 。 注 意 ,虽然 在 10.2 版 本 中 使 用 的 是 
正常 的 作业 ,但 是 从 11.1 版 本 开始 起 ， 会 将 收集 过 程 集成 在 自动 维护 任务 里 面 。 在 两 种 情况 下 ,任务 
都 是 使 用 dbms_scheduler 包 调度 的 ， 而 不 是 dboms_job 包 。 


警告 在 11.2 及 之 前 的 版 本 中 ,默认 情况 下 任务 的 目标 是 除了 固定 表 以 外 的 所 有 对 象 。 因 此 ， 你 必须 
自己 在 数据 库 引 擎 负载 高 峰 期 处 理 国定 表 的 对 象 统计 信息 收集 的 工作 。 建 议 在 负载 高 峰 期 收 
集 数 据 是 因为 固定 表 的 内 容 强烈 依赖 于 负载 。 例 如 x$ksuse 表 ， 它 为 每 个 会 话 包含 一 条 记录 。 


下 面 两 个 小 节 的 主要 目标 是 提供 关于 用 于 调度 默认 作业 的 配置 的 详细 信息 。 其 中 第 一 节 介绍 10g 
版 本 。 第 二 节 介 绍 后 续 的 版 本 。 


8.8.1 ” 10g 方式 


gather_stats_job 是 在 10g 版 本 中 自动 设置 的 作业 。 其 当前 的 配置 ， 也 就 是 下 面 示例 中 10.2 版 本 的 
默认 配置 ， 可 以 通过 下 面 的 查询 显示 出 来 。 输 出 是 通过 dbms_stats job 10g.sql 脚 本 生成 的 : 


SQL> SELECT program name, schedule name, enabled, state 
2 FROM dba scheduler jobs 
3 WHERE owner = “SYS 
4 AND job name = 'GATHER STATS JOB'; 


PROGRAM NAME SCHEDULE NAME ENABLED STATE 


GATHER_STATS PROG MAINTENANCE WINDOW GROUP TRUE SCHEDULED 


SQL> SELECT program action, number of arguments, enabled 
2 FROM dba scheduler programs 
3 WHERE owner = “SYS" 
4 AND program name = 'GATHER STATS PROG'; 


PROGRAM ACTION NUMBER OF _ ARGUMENTS ENABLED 


dbms_stats.gather database stats job proc 0 TRUE 
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SQL> SELECT Ww.window name, w.repeat interval, w.duration, w.enabled 
2 FROM dba scheduler jobs j, dba scheduler wingroup members m, 
3 dba_scheduler windows WwW 
4 WHERE j.schedule name = m.window group_name 
5 AND m.window name = w.window name 
6 AND j.owner = 'SYS" 
7 AND j.job name = 'GATHER STATS JOB'; 


WINDOW_NAME REPEAT INTERVAL DURATION ENABLED 


WEEKNIGHT WINDOW freq=daily;byday=MON, TUE, WED, THU, FRI; +000 08:00:00 TRUE 
byhour=22;byminute=0; bysecond=0 

WEEKEND WINDOW freq=daily;byday=SAT;byhour=0;byminut +002 00:00:00 TRUE 
e=0;bysecond=0 


总 结 起 来 ， 其 配置 如 下 。 

口 作业 执行 gather_stats_prog 程 序 并 且 可 以 在 maintenance_window_group 窗 口 组 中 运行 。 

口 gather_stats_prog 程 序 不 使 用 任何 参数 调用 dbms_stats 包 的 gather database_stats_job_proc 
存储 过 程 。 因 为 没有 任何 参数 传递 进来 ， 唯 一 能 够 改变 此 存储 过 程 行为 的 办 法 就 是 改变 
dbms_stats 包 的 默认 配置 ， 正 如 8.4 节 中 介绍 的 那样 。 注 意 这 个 存储 过 程 是 未 公开 的 ， 并 被 标 
记 为 “ 仅 供 内 部 使 用 ”。 

口 maintenance_window_group 窗 口 组 有 两 个 成 员 : weeknight_window 窗 口 和 weekend_window 和 窗口 。 
前 者 从 星期 一 到 星期 五 每 天 晚上 开放 八 个 小 时 。 后 者 在 星期 六 和 星期 日 开放 。 收 集 对 象 统计 
言 息 的 任务 在 这 两 个 窗口 中 的 一 个 打开 时 执行 。 

口 作业 、 程 序 以 及 窗口 都 是 启用 的 。 

应 该 检查 默认 调度 程序 的 开放 时 间 和 持续 时 长 ,并 且 在 必要 的 时 候 , 改变 它 们 以 精确 匹配 统计 信 

息 收集 的 频率 。 如 有 可 能 ,它们 应 该 匹配 低 负载 的 时 间 有 段 。 
每 次 作业 因为 窗口 关闭 而 停止 运行 ,都 会 产生 一 个 包含 所 有 没有 来 得 及 处 理 的 对 象 列表 的 跟踪 文 
件 ， 并 写 和 人 到 由 background_dump_dest 初 始 化 参数 指定 的 目录 中 。 下 面 是 对 这 种 跟踪 文件 的 一 段 摘 录 : 


GATHER_STATS JOB: Stopped by Scheduler. 

Consider increasing the maintenance window duration if this happens frequently. 
The following objects/segments were not analyzed due to timeout: 

TABLE: "SH"."SALES"."SALES 1995" 

TABLE: "SH"."SALES"."SALES 1996" 

TABLE: "SH"."SALES"."SALES H1 1997" 


TABLE: "SYS"."WRI$ OPTSTAT AUX_HISTORY"."" 

TABLE: "SYS"."WRI$ ADV OBJECTS"."" 

TABLE: "SYS"."WRI$ OPTSTAT_ HISTGRM HISTORY"."" 

error 1013 in job queue process 

ORA-01013: user requested cancel of current operation 


要 启用 或 禁用 gather_stats_job 作 业 ， 可 以 使 用 下 面 的 PL/SQL 调 用 : 


dbms_scheduler.enable(name => 'sys.gather stats job') 


dbms_scheduler.disable(name => 'sys.gather stats job ') 
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默认 情况 下 ， 只 有 sys 用 户 能 够 执行 这 些 调用 。 其 他 用 户 需 要 alterobject 权 限 。 举 例 来 说 ， 通 过 
执行 下 面 的 SQL 语句 ，system 用 户 不 仅 能 够 修改 而 且 也 能 删除 gather_stats job 作业 : 
GRANT ALTER ON gather _ stats job TO system 


8.8.2 119 和 12c 方 式 


从 11.1 版 本 开始 ， 对 象 统计 信息 的 收集 被 集成 到 自动 维护 任务 中 。 所 以 ， 上 一 节 中 描述 的 
gather_stats_job 作 业 就 不 复 存在 了 。 当 前 的 配置 , 也 就 是 下 面 例子 中 11.2 版 本 的 默认 配置 , 可 以 通过 
下 面 的 查询 显示 出 来 。 输 出 部 分 是 由 dbms_stats_job_11g.sql 脚 本 生成 的 : 


SQL> SELECT task name, status 
2 FROM dba autotask task 
3 WHERE client name = 'auto optimizer stats collection’'; 


TASK_NAME STATUS 


gather stats prog ENABLED 


SQL> SELECT program action, number of arguments, enabled 


2 FROM dba scheduler programs 

3 WHERE owner = “SYS' 

4 AND program name = 'GATHER STATS PROG'; 
PROGRAM ACTION NUMBER_OF_ARGUMENTS ENABLED 
dbms_stats.gather database stats job proc 0 TRUE 


SQL> SELECT window group 
2 FROM dba autotask client 
3 WHERE client name = "auto optimizer stats collection'; 


WINDOW GROUP 


ORA$AT_WGRP_OS 


SQL> SELECT w.window name, w.repeat interval, w.duration, w.enabled 
2 FROM dba autotask window clients c, dba scheduler windows w 
3 WHERE c.window name = w.window name 
4 AND c.optimizer stats = 'ENABLED'; 


WINDOW NAME REPEAT INTERVAL DURATION ENABLED 
MONDAY_WINDOW freq=daily;byday=MON;byhour=22;byminute=0; bysecond=0 +000 04:00:00 TRUE 
TUESDAY WINDOW freq=daily;byday=TUE;byhour=22; ;byminute=0; bysecond=0 +000 04:00:00 TRUE 
WEDNESDAY WINDOW freq=daily;byday=WED;byhour=22;byminute=0; bysecond=0 +000 04:00:00 TRUE 
THURSDAY WINDOW freq=daily;byday=THU;byhour=22;byminute=0; bysecond=0 +000 04:00:00 TRUE 
FRIDAY WINDOW freq=daily;byday=FRI;byhour=22;byminute=0; bysecond=0 +000 04:00:00 TRUE 
SATURDAY WINDOW freq=daily;byday=SAT;byhour=6;byminute=0; bysecond=0 +000 20:00:00 TRUE 
SUNDAY WINDOW freq=daily;byday=SUN;byhour=6;byminute=0; bysecond=0 +000 20:00:00 TRUE 


总 结 起 来 ， 其 配置 如 下 。 
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口 gather_stats_prog 程 序 不 使 用 任何 参数 调用 dbms_stats 包 的 gather_database_stats job_proc 
过 程 。 因 为 没有 任何 参数 传递 进来 ， 唯 一 能 够 改变 此 过 程 的 行为 的 办 法 就 是 改变 dbms_stats 
包 的 默认 配置 ， 如 8.4 节 所 述 。 注 意 这 个 过 程 是 未 公开 的 ， 并 被 标记 为 “ 仅 供 内 部 使 用 "。 
口 用 于 自动 维护 任务 的 窗口 组 有 七 个 成 员 ， 一 个 星期 中 的 每 一 天 对 应 一 个 。 从 星期 一 到 星期 五 ， 
每 天 开放 四 个 小 时 。 从 星球 六 到 星期 上 日， 每 天 开放 20 个 小 时 。 收 集 对 象 统计 信息 的 任务 会 在 
这 些 窗 口中 的 一 个 打开 时 执行 。 注 意 当 一 个 窗口 打开 了 很 长 时 间 后 ， 例 如 在 周末 ， 
gathez stats_prog 程 序 每 隔 四 个 小 时 重启 一 次 。 
口 维护 任务 、 程 序 以 及 窗口 都 是 启用 的 。 
应 检查 默认 调度 程序 的 开放 时 间 和 持续 时 长 , 并 且 在 必要 的 时 候 , 改变 它们 以 精确 匹配 统计 信息 
收集 的 频率 。 如 有 可 能 ， 它 们 应 该 匹配 低 负 载 的 时 间 段 。 
要 完全 启用 或 禁用 维护 任务 ， 可 以 使 用 下 面 的 PL/SQL 调 用 : 通过 将 windows_name 人 参数 设置 为 一 个 
非 空 值 ， 还 可 以 为 一 个 单独 的 窗口 启用 或 禁用 维护 任务 。 


dbms auto task admin.enable(client name => "auto optimizer stats Collection ， 
operation => NULL, 
window_ name => NULL) 


dbms auto task admin.disable(client name => 'auto optimizer stats collection', 
operation => NULL， 
window name => NULL) 


警告 ”从 11.2 版 本 开始 ， 将 job queue _processes 初 始 化 参数 设置 为 0 即 可 禁用 自动 统计 信息 作业 ( 以 
及 其 他 所 有 通过 该 Scheduler 调 度 的 任务 )。 
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无 论 何 时 通过 dbms_stats 包 收集 了 对 象 统计 信息 ， 或 者 从 11.2 版 本 开始 ， 用 ALTER INDEX 语 名 取代 
简单 地 使 用 新 的 统计 信息 覆盖 当前 统计 信息 ， 当 前 统计 信息 都 会 被 存储 到 其 他 数据 字典 表 中 ,并 保存 
一 份 在 保留 期 内 出 现 变化 的 所 有 历史 记录 。 其 用 途 是 , 万 一 新 的 统计 信息 导致 了 效率 低下 的 执行 计划 ， 
可 以 还 原 旧 的 统计 信息 。 

对 象 统计 信息 在 历史 中 保存 一 段 由 保留 期 指定 的 时 间 间 隔 ( 系统 统计 信息 也 是 这 样 ， 因 为 它们 是 
由 相同 的 基础 功能 维护 的 )。 默 认 值 是 31 天 。 可 以 通过 调用 dbms_stats 包 的 get_stats_history 
retention 消 数 来 显示 当前 值 ， 如 下 所 示 : 

SELECT dbms stats.get stats history retention() AS retention FROM dual 

要 修改 保留 期 ， 可 以 使 用 dbms_stats 包 提供 的 alter_stats_history_retention 存 储 过 程 。 下 面 是 

一 个 将 保留 期 设置 为 14 天 的 调用 例子 : 
dbms_stats.alter stats history retention(retention => 14) 
注意 ， 使 用 alter stats _history retention 存 储 过 程 时 ， 下 面 的 值 有 特殊 意义 。 
口 NULL 会 将 保留 期 设置 为 默认 值 。 
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口 0 会 禁用 历史 记录 。 
口 -1 会 禁用 历史 记录 的 清除 。 

将 statistics level 初始 化 参数 设置 为 typical ( 默认 值 ) 或 者 all 时 , 时间 超 出 保留 期 的 统计 信息 
会 被 自动 清除 掉 。 一 旦 有 必要 进行 手工 清除 时 ， 可 以 使 用 dbms_stats 包 提供 的 purge_stats 存 储 过 程 。 
下 面 的 调用 清除 历史 记录 中 所 有 超过 14 天 的 统计 信息 : 

dbms stats.purge stats(before timestamp => systimestamp - INTERVAL '14' DAY) 

要 执行 alter stats history retention 和 purge_stats 存 储 过 程 ， 需 要 有 analyze any 和 analyze any 
dictionary 系 统 权 限 。 

如 果 想 知道 对 于 一 张 给 定 的 表 它 的 对 象 统计 信息 何 时 被 修改 过 ，user_tab_stats_history 数 据 字 
典 视 图 可 以 提供 所 有 必要 的 信息 。 当然 了 , 还 有 dba、all 以 及 12.1 版 本 中 多 租户 环境 下 的 cdb 版 本 可 用 。 
下 面 是 一 个 例子 。 通 过 下 面 的 查询 ， 可 以 显示 sys 模 式 下 的 tab$ 表 的 对 象 统计 信息 的 修改 时 间 : 

SQL> SELECT stats update time 


2 FROM dba tab stats history 
3 WHERE owner = 'SYS' and table name = 'TAB$'; 


STATS UPDATE_ TIME 


26-MAR-14 22.03.03.104730 +01:00 
27-MAR-14 22.01.14.193033 +01:00 
13-APR-14 14.14.57.461660 +02:00 


无 论 什 么 时 候 ， 如 果 有 必要 ， 都 可 以 从 历史 记录 中 还 原 统计 信息 。 出 于 这 个 目的 ，dbms_stats 提 
供 以 下 存储 过 程 。 
口 restore_database_stats 为 整个 数据 库 还 原 对 象 统计 信息 。 
口 restore dictionary_stats 为 数据 字典 还 原 对 象 统计 信息 。 
口 restore fixed objects_stats 为 固定 表 及 其 索引 还 原 对 象 统计 信息 。 
口 restore_schema_stats 为 单个 模式 还 原 对 象 统计 信息 。 
口 restore table stats 为 单 张 表 还 原 对 象 统计 信息 。 
除了 指定 目标 的 参数 之 外 ( 例如 ，restore table_stats 过 程 的 模式 和 表 名 )， 所 有 这 些 存 储 过 程 
都 提供 以 下 参数 。 
口 as_of timestamp 指 定 将 统计 信息 还 原 至 某 一 特定 的 时 间 点 。 
口 force 指 定 是 否 可 以 覆盖 锁定 的 统计 信息 。 注 意 统计 信息 上 的 锁 也 是 历史 记录 的 一 部 分 。 这 就 
意味 着 关于 统计 信息 的 状态 信息 ( 锁定 与 否 ) 也 可 以 被 还 原 。 默 认 值 为 FALSE。 
口 no_invalidate 指 定 依赖 于 被 覆盖 的 统计 信息 的 游标 是 否 失 效 。 这 个 参数 接受 的 值 为 TRUE、 
FALSE， 还 有 dbms _ stats.auto_invalidate。 默 认 值 是 dbms_stats.auto_invalidate。 
下 面 的 调用 将 SH 模 式 下 的 对 象 统计 信息 还 原 为 一 天 以 前 使 用 的 值 。 因 此 ,force 参 数 被 设置 为 TRUE 
时 ， 即 使 当前 统计 信息 是 锁定 状态 也 会 被 还 原 : 


dbms_stats.restore schema stats(ownname => 'SH", 
as of timestamp => systimestamp - INTERVAL '1' DAY, 
force => TRUE) 
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8.10 ”锁定 对 象 统计 信息 


在 某 些 情况 下 ， 可 能 需要 确保 数据 库 的 部 分 对 象 统计 信息 不 可 用 或 者 不 允许 修改 ， 这 是 因为 需要 
使 用 动态 采样 ( 见 第 9 章 ), 或 者 必须 使 用 非 最 新 的 对 象 统计 信息 ( 例如 ， 因 为 某 些 表 的 内 容 变 化 非常 
频繁 ,你 希望 只 有 在 这 些 表 包含 了 一 组 有 代表 性 的 数据 时 才 小 心地 收集 其 状态 )， 也 可 能 因为 收集 统 
计 信息 不 可 行 ( 例 如， 出 现 了 bug )。 
可 以 通过 执行 下 面 的 doms_stats 包 中 的 存储 过 程 来 显 式 锁定 对 象 统计 信息 。 注 意 这 些 锁 和 通常 所 
说 的 数据 库 锁 没有 任何 关系 。 实 际 上 ， ee 
口 lock_schema_stats 锁 定 属于 某 个 模式 下 的 所 有 表 的 对 象 统计 信息 : 
dbms_stats.lock schema_stats(ownname => user) 
口 lock_table_stats 锁 定单 张 表 的 对 象 统计 信息 : 
dbms_stats.lock table stats(ownname => user, tabname => 'T') 
当然 ， 也 可 以 移 除 这 些 锁 ， 你 可 以 通过 以 下 存储 过 程 中 的 一 个 来 完成 。 
口 unlock_schena_stats 解 除 某 个 模式 下 所 有 表 的 对 象 统计 信息 上 的 锁定 ， 
dbms_stats.unlock schema stats(ownname => user) 
口 unlock_table_stats 解 除 单 张 表 的 对 象 统计 信息 上 的 锁定 : 
dbms_stats.unlock table stats(ownname => user, tabname => 'T') 
要 执行 这 四 个 存储 过 程 ， 需 要 以 所 有 者 身份 登录 或 者 拥有 analyze any 系 统 权限 。 
锁定 了 某 张 表 的 对 象 统计 信息 时 ,会 将 与 访 表 相关 的 所 有 对 和 象 统计 信息 ( 包括 表 统 计 信息 、 列 统 
计 信息 、 直 方 图 以 及 所 有 依赖 索引 的 索引 统计 信息 ) 都 视 为 锁定 的 。 
锁定 了 某 张 表 的 对 象 统计 信息 的 情况 下 ，dbms_stats 包 中 修改 单 张 表 的 对 象 统计 信息 的 过 程 ( 例 
如 gather table stats ) 会 引发 一 个 错误 ( ORA-20005 )。 与 此 相反 ， 操 作 多 张 表 的 过 程 〈 例如 
gather_schema_stats ) 会 跳 过 锁定 的 表 。 大 多 数 修改 对 象 统计 信息 的 过 程 能 够 通过 将 force 参 数 设置 
为 TRUE 来 覆盖 锁定 。 下 面 的 例子 演示 了 这 种 行为 ( 完整 示例 参见 lock_statistics.sql 脚 本 ): 


SOL> BEGIN 
2 dbms_stats.lock schema stats(ownname => user); 
3 END; 
4 / 


SQL> BEGIN 
2 dbms_stats.gather schema stats(ownname => user); 
3 END; 
4 7/ 


SQL> BEGIN 


2 dbms_stats.gather table stats(ownname => user, 
3 tabname => 'T'); 


ERROR at line 1: 
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ORA-20005: object statistics are locked (stattype = ALL) 
ORA-06512: at "SYS.DBMS STATS", line 33859 
ORA-06512: at line 2 


SQL> BEGIN 
2 dbms_ stats.gather table stats(ownname => user, 


3 tabname => 'T', 
4 force => TRUE); 
5 END; 

6 7 


要 想 知道 哪些 表 的 对 象 统计 信息 被 锁定 了 ， 可 以 使 用 类 似 下 面 这 样 的 查询 : 


SQL> SELECT table name 
2 FROM user tab statistics 
3 WHERE stattype locked IS NOT NULL; 


TABLE_ NAME 


要 知道 并 非 只 有 dbms_stats 包 会 收集 对 象 统计 信息 ， 因 此 ， 也 不 是 只 有 它 才 会 受 对 象 统计 信息 上 
的 锁 影 响 。 实 际 上 ，ANALYZE 、CREATE INDEX 和 ALTER INDEX 语 句 ， 以 及 12.1 及 之 后 版 本 的 CTAS 语 句 和 
向 空 表 执行 直接 路 径 插入 , 也 都 会 收集 对 象 统计 信息 。 ANALYZE 语 句 会 在 被 明确 告知 时 收集 对 象 统计 信 
息 。 但 是 ， 如 本 章 开头 所 述 ， 你 不 应 该 再 使 用 这 个 语句 收集 统计 信息 。 其 余 的 语句 会 在 执行 它们 分 配 
的 任务 时 自动 收集 对 象 统计 信息 。 这 样 做 很 有 意义 ， 因 为 执行 这 些 SQL 语句 时 收集 统计 信息 的 开销 可 
以 忽略 不 计 。 所 以 ， 锁 定 了 表 的 对 象 统计 信息 时 ， 以 上 这 些 SQL 语句 的 行为 可 能 会 有 所 不 同 或 者 甚至 
会 失败 。 下面 的 例子 作为 上 一 个 例子 的 延续 ， 展 示 了 这 种 行为 : 

SOL> ANALYZE TABLE t COMPUTE STATISTICS; 

ANALYZE TABLE t COMPUTE STATISTICS 


ERROR at line 1: 
ORA-38029: object statistics are locked 


SOL> ANALYZE TABLE 七 VALIDATE STRUCTURE; 


SQL> ALTER INDEX t pk REBUILD COMPUTE STATISTICS; 
ALTER INDEX t pk REBUILD COMPUTE STATISTICS 
* 


ERROR at line 1: 
ORA-38029: object statistics are locked 


SQL> ALTER INDEX t pk REBUILD; 


SQL> CREATE INDEX t i ON t (pad) COMPUTE STATISTICS; 
CREATE INDEX t i ON t (pad) COMPUTE STATISTICS 
水 


ERROR at line 1: 
ORA-38029: object statistics are locked 


SOL> CREATE INDEX t i ON t (pad); 
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注意 ，SQL 语 名 CREATE INDEX 和 ALTER INDEX 只 有 在 指定 了 不 推荐 使 用 的 COMPUTE STATISTICS 子 句 
时 才 会 失败 。 因 为 这 些 SQL 语 句 都 会 默认 收集 对 象 统计 信息 ， 使 用 COMPUTE STATISTICS 子 句 完全 没有 
意义 。 


8.11 比较 对 象 统计 信息 


在 下 面 三 种 常见 情形 中 ， 你 最 终 会 为 同一 个 对 象 生成 多 组 对 象 统计 信息 。 

口 当 你 命令 dbms stats 包 ( 通过 参数 statown 、stattab 和 statid ) 将 当前 对 象 统计 信息 保存 到 备 
份 表 中 时 。 

口 dbms_stats 包 被 用 于 收集 对 象 统计 信息 时 。 事 实 上 ， 如 8.9 节 所 述 ， 当 收集 一 组 新 的 统计 信息 
时 ， 程 序 包 会 自动 保存 对 象 统计 信息 的 历史 记录 而 不 是 简单 地 对 其 进行 覆盖 。 

口 从 11.1 版 本 开始 ， 当 你 收集 挂 起 的 统计 信息 时 。 

通常 情况 下 你 希望 了 解 两 组 对 象 统计 信息 之 间 的 不 同 。 自 10.2.0.4 版 本 开始 , 你 不 再 需要 自己 动手 

写 查 询 语 句 完 成 这 样 的 比较 。 可 以 简单 地 利用 dbms_stats 包 提供 的 新 函数 。 
下 面 的 例子 基于 comparing object statistics.sql 脚 本 输出 ， 显 示 了 此 类 报告 : 


持 提 ## 划 ## 并 村 # 打 并 村 扩 失禁 失 村 提 村 村 守 失 夫 检 检 间 村 村 失 术 村 失 失 林村 村 村 村 提 提 井村 共 提 扩 扩 打 失 入 失禁 失 失 检 提 守 扩 入 村 和 失 村 并 村 失 村 失守 失 失 村 失 失 失守 柑 ## 圭 衬 检 


STATISTICS DIFFERENCE REPORT FOR: 


es 


TABLE : T 

OWNER : CHRIS 

SOURCE A : Statistics as of 10-APR-13 20.05.07.106712 +02:00 
SOURCE B : Current Statistics in dictionary 


PCTTHRESHOLD : 10 


NT 


OQBJECTNAME TYP SRC ROWS BLOCKS ROWLEN SAMPSIZE 
各 T A 10088 110 37 5865 
B 12691 253 37 5036 


并 mm 


COLUMN NAME SRC NDV DENSITY HIST NULLS LEN MIN MAX SAMPSIZ 


CE 


ID A 9862 .000101399 NO 0 4 C103 (C2646 5734 
B 12645 .000079082 NO 0 5 C108 C3026 5018 
VAL1 A 3203 .000454959 YES 0 : 3D382 C2240 5779 
B 2990 .000489236 YES 0 | 3D421 C2251 4926 
VAL2 A 9 .000049759 YES 0 3 C1i0C (C114 5842 
B 9 .000039438 YES 0 3 C10C (C114 5031 


NII 


INDEX / (SUB)PARTITION STATISTICS DIFFERENCE: 
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so eo 0 so 0800000000. 


OBJECTNAME TYP SRC ROWS LEAFBLK DISTKEY LF/KY DB/KY CLF LVL SAMPSIZ 
INDEX: T_PK 
T_RK TI A 10000 20 10000 1 1 9901 1 10000 
B 12500 27 12500 1 1 12300 1 12500 


提 拉 拓 提 提 挂失 提 提 扩 入 村 村 入 村 村 村 拌和 和 入 持 失 村 村 村 村 村 村 村 和 村 拉 失 竺 村 入 竺 折 折 村 村 村 村 村 和 村 村 拉 并 并 拭 村 提 提 和 
注意 开头 部 分 的 内 容 ， 你 可 以 看 到 用 于 比较 的 参数 : 模式 和 表 的 名 称 、 两 个 比较 源 的 定义 ( A 和 
B ) 以 及 一 个 阔 值 。 最 后 的 这 个 参数 指定 是 否 只 显示 两 组 统计 信息 之 间 的 差异 ( 按 百 分 比 ) 达到 指定 
阅 值 的 那些 对 象 统计 信息 。 例 如 ,如 果 你 有 两 个 值 100 和 115, 仅 当 阅 值 设置 为 15 或 者 更 低 的 时 候 它 们 
会 被 认为 是 不 同 的 。 默 认 的 阔 值 是 10。 要 显示 所 有 的 对 象 统计 信息 ， 可 以 使 用 值 0。 
下 面 是 dbms_stats 包 中 可 以 用 来 生成 这 样 的 报告 的 函数 。 
口 diff table stats in_ stattab 用 于 比较 一 张 备份 表 ( 通过 参数 ownname 和 tabname 指 定 ) 中 的 对 
象 统计 信息 与 当前 对 象 统计 信息 之 间 的 差异 ,或 者 比较 其 与 男 外 一 张 备份 表 中 的 另 一 组 信息 
之 间 的 差异 。 参 数 stattab1、statidi 以 及 stattabiown 用 来 指定 第 一 张 备份 表 。 第 二 张 备 份 表 
( 此 处 是 可 选 的 ) 是 通过 参数 stattab2、statid2 以 及 stattab2own 指 定 的 。 如 果 第 二 张 备份 表 
的 参数 没有 指定 , 或 者 它们 被 设置 为 NULL, 那么 当前 对 象 统计 信息 就 会 与 第 一 张 备份 表 的 对 象 
统计 信息 进行 比较 。 下 面 的 例子 将 当前 对 象 统计 信息 与 一 组 存储 在 mystats 备 份 表 中 、 名 为 set1 
的 对 象 统计 信息 进行 比较 : 


dbms _stats.diff table stats in stattab(ownname =» USET, 
tabname s% TT 
stattab1 3 "MYSTATS"; 
statid1 = "SETL , 


stattab1own => UseT， 
pctthreshold => 10) 


口 diff table stats in history 比 较 一 张 表 的 当前 对 象 统计 信息 与 历史 记录 中 的 对 象 统计 信息 ， 
或 者 比较 这 张 表 历史 记录 中 的 两 组 对 象 统计 信息 。 参数 timel1 和 time2 用 来 指定 使 用 哪些 对 象 统 
计 信 息 比较 。 如 果 time2 没 有 指定 ,或 者 设置 为 NULL， 则 当前 对 象 统计 信息 与 历史 记录 中 的 另 
一 组 进行 比较 。 下 面 的 例子 将 当前 对 象 统计 信息 与 一 天 之 前 的 对 象 统计 信息 ( 例如 ， 在 夜间 
执行 的 统计 信息 收集 之 前 的 对 象 统计 信息 ) 进行 比较 : 


dbms_ stats.diff table stats in history(ownname = USer, 
tabname > 
time1 => systimestamp - 1， 
time2 => NULL, 


pctthreshold => 10)); 

口 diff table stats in pending 将 一 张 表 的 当前 对 象 统计 信息 或 者 历史 记录 中 的 一 组 信息 , 与 挂 
起 的 统计 信息 进行 比较 。 要 想 指定 存储 在 历史 记录 中 的 对 象 统计 信息 ， 可 以 使 用 参数 
time_stamp。 如 果 这 个 参数 设置 为 NULL ( 默认 值 )， 则 当前 对 象 统计 信息 与 挂 起 的 统计 信息 进 
行 比较 。 下 面 的 例子 将 当前 的 统计 信息 与 挂 起 的 统计 信息 进行 比较 : 
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dbms_stats.diff table stats in pending(ownname => User, 
tabname = 
time stamp => NULL, 
pctthreshold => 10)); 


8.12 删除 对 象 统计 信息 


可 以 从 数据 字典 中 删除 对 象 统计 信息 。 除 非 是 测试 需要 ， 和 否则 通常 没有 必要 这 样 做 。 虽 然 如 此 ， 
但 也 可 能 出 现 你 想 利 用 动态 采样 ( 参见 第 9 章 ) 而 不 希望 某 张 表 上 有 对 象 统计 信息 的 情况 。 如 果 那 样 
的 话 ， 就 可 以 使 用 dbms_stats 包 中 的 下 列 过 程 : delete database_stats、delete dictionary_stats、 
delete fixed _ objects_stats、delete_ schema_stats、delete table stats、 delete column_stats 以 及 
delete _ index_stats。 

正如 你 所 看 到 的 , 对 于 每 个 gather_*_stats 过 程 , 都 有 一 个 对 应 的 delete_*_stats 过 程 。 前 者 收集 
对 象 统计 信息 ， 后 者 删除 对 象 统计 信息 。 唯 一 的 例外 是 delete column_stats 过 程 。 顾 名 思 义 ， 它 用 来 
删除 列 统计 信息 和 直方 图 。 

表 8-8 总 结 了 这 些 过 程 中 的 每 一 个 可 以 使 用 的 参数 。 大 部 分 参数 是 相同 的 ， 因 而 它们 与 
gather_*_stats 过 程 中 使 用 的 参数 具有 相同 的 含义 。 这 里 只 描述 一 些 在 之 前 的 过 程 中 尚未 涉及 的 参数 

口 cascade_parts 指 定 是 否 删除 所 有 底层 分 区 的 统计 信息 。 这 个 参数 接受 的 值 为 TRUE 和 FALSE。 默 


认 值 为 TRUE。 

口 cascade_columns 指 定 是 否 同时 删除 列 统计 信息 。 这 个 参数 接受 的 值 为 TRUE 和 FALSE。 上 默认 值 为 
TRUE. 

口 cascade_indexes 指 定 是 否 同时 删除 索引 统计 信息 。 这 个 参数 接受 的 值 为 TAUE 和 FALSE。 默 认 值 
为 TRUE 。 


口 col_stat_type 指 定 删除 哪些 统计 信息 。 如 果 将 它 设置 为 ALL， 则 删除 列 统计 信息 和 直方 图 。 如 
果 将 它 设置 为 HISTOGRAM， 则 只 删除 直方 图 。 默 认 值 是 NULL。 这 个 参数 从 11.1 版 本 开始 可 用 。 
口 stat_category 指 定 删除 哪 种 类 别 的 统计 信息 。 它 接受 以 逗号 分 隔 的 列表 形式 的 值 。 如 果 指 定 
了 0B]JECT_STATS， 则 对 象 统 计 信息 ( 表 统 计 信息 、 列 统计 信息 、 直 方 图 以 及 索引 统计 信息 ) 会 
被 删除 。 如 果 指 定 了 SYNOPSES， 则 只 有 支持 增 量 统计 信息 的 信息 会 被 删除 。 默 认 情 况 下 ， 对 象 

统计 信息 和 概要 信息 都 会 被 删除 。 这 个 参数 从 12.1 版 本 开始 可 用 。 


表 8-8 ”用 于 删除 对 象 统计 信息 的 过 程 的 参数 


参 数 数据 库 数据 字典 固定 表 模 式 表 列 索引 

目标 对 象 

ownname 到 st 
indname 
tabname i a 

colname a 

partname 5 > 
Cascade parts Vv WA V 


cascade_ columns 
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( 续 ) 

参 数 数据 库 数据 字典 固定 表 模 式 表 列 索引 
cascade_indexes a 
stat category Vs :A 过 a 
col stat type 这 
force Vv Vv Vv Vv Vv 以 Vv 
删除 选项 
no_invalidate a Vv VV Vv Vv Vv Vv 
备份 表 
stattab A a i we a Y Nd 
statid Vv VvV Vv Vv VvV Vv V 
statown wy V AAA AAA Vv Vv Vv 


下 面 的 调用 展示 了 如 何在 不 修改 其 他 统计 信息 的 精 况 下 删除 一 个 列 的 直方 图 ( 完整 示例 参见 
delete histogram.sql ): 


dbms_stats.delete column_ stats(ownname => User, 
tabname => T， 
colname "sy VAL'; 


col_ stat type => 'HISTOGRAM') 


8.13” 导 出、 导入 、 获 取 和 设置 对 象 统计 信息 


如 图 8-1 所 示 ,， 除 了 用 于 收集 统计 信息 的 过 程 和 函数 之 外 , dbms_stats 包 还 提供 了 其 他 几 个 可 用 的 
过 程 和 函数 。 在 这 里 不 会 介绍 它们 ， 因 为 它们 在 实践 中 很 少 使 用 。 相 关 信 息 请 查看 Oracle Database 
PL/SOL Packages and Types Rejerence 手 册 。 尽 管 如 此 ， 我 还 是 想 分 享 一 下 下 面 这 个 你 在 文档 中 找 不 到 
的 小 知识 。 


警告 ”由 dbms stats 包 提供 的 导出 和 导入 过 程 使 用 8.10 节 中 描述 的 技术 来 处 理 锁定 问题 。 唯 一 的 例 
外 ， 仅 会 出 现在 11.2.0.2 之 前 的 版 本 中 ， 与 没有 对 象 统计 信息 的 表 有 关 。 对 于 这 样 的 表 ， 当 它 
们 的 对 象 统 计 信 息 被 导出 或 者 导入 后 ， 其 统计 信息 的 锁 就 会 消失 。 


8.14 ”管理 操作 的 日 志 记 录 
dbms_stats 包 中 的 许多 过 程 在 数据 字典 中 记录 关于 它们 的 执行 的 信息 。 这 些 日 志 信 息 通 过 
dba_optstat_operations 以 及 在 12.1 多 租户 环境 下 的 cdb_optstat_operations 视 图 来 予以 展现 。 基本 上 , 你 


可 以 查 到 执行 了 哪些 操作 ， 它 们 是 什么 时 候 开 始 执 行 的 以 及 执行 了 多 久 。 从 12.1 版 本 开始 ， 关 于 状态 "、 
会 话 以 及 与 操作 相关 的 作业 信息 ( 可 选 ) 都 可 以 访问 。 接 下 来 的 例子 摘自 一 个 生产 数据 库 ， 显 示 了 


GD 可 能 出 现 的 值 有 : PENDING 、IN PROGRESS 、COMPLETED 、FAILED 、SKIPPED 以 及 TIMED OUT。 
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gather database_ stats 过 程 每 天 都 会 启动 并 花费 9~18 分 钟 来 执行 ( 注意 ，2014 年 4 月 5 、6 日 是 周末 ): 


SQL> SELECT operation, start time, 
2 (end time-start time) DAY(1) TO SECOND(0) AS duration 
3 FROM dba optstat operations 
4 ORDER BY start time DESC; 


OPERATION START_TIME DURATION 

gather database stats(auto) 09-APR-14 10.00.08.877925 PM +02:00 +0 00:10:28 
gather database stats(auto) 08-APR-14 10.00.02.899209 PM +02:00 +0 00:09:30 
gather database stats(auto) 07-APR-14 10.00.04.119250 PM +02:00 +0 00:12:45 
gather database stats(auto) 06-APR-14 10.05.00.173419 PM +02:00 +0 00:00:55 
gather database stats(auto) 06-APR-14 06.04.46.957190 PM +02:00 +0 00:00:50 
gather database stats(auto) 06-APR-14 02.04.32.438573 PM +02:00 +0 00:00:53 
gather database stats(auto) 06-APR-14 10.04.16.208319 AM +02:00 +0 00:01:27 
gather database stats(auto) 06-APR-14 06.00.09.299059 AM +02:00 +0 00:04:55 
gather database_stats(auto) 05-APR-14 10.03.28.888807 PM +02:00 +0 00:00:58 
gather database stats(auto) 05-APR-14 06.03.14.637546 PM +02:00 +0 00:00:43 
gather database stats(auto) 05-APR-14 02.02.59.997594 PM +02:00 +0 00:01:06 
gather database stats(auto) 05-APR-14 10.02.46.052860 AM +02:00 +0 00:01:13 
gather database stats(auto) 05-APR-14 06.00.03.801439 AM +02:00 +0 00:06:05 
gather database stats(auto) 04-APR-14 10.00.03.068541 PM +02:00 +0 00:17:32 
gather database stats(auto) 03-APR-14 10.00.02.781440 PM +02:00 +0 00:06:59 
gather database stats(auto) 02-APR-14 10.00.02.702294 PM +02:00 +0 00:12:45 
gather database stats(auto) 01-APR-14 10.00.03.254860 PM +02:00 +0 00:12:48 


此 外 ， 从 12.1 版 本 开始 ， 你 可 以 查询 到 某 个 操作 执行 时 使 用 的 参数 。 例 如 ， 下 面 的 查询 展示 了 默 
认 收 集 作 业 的 最 后 一 次 执行 都 使 用 了 哪些 参数 : 


SQLS SELECT XX,* 
2 FROM dba optstat operations 0， 
3 XMLTable( '/params/param’ 


4 PASSING XMLType(notes ) 
5 COLUMNS name VARCHAR2(20) PATH ‘'@name', 
6 value VARCHAR2(30) PATH '@val') x 
7 WHERE operation = 'gather database stats (auto)’ 
8 AND start time = (SELECT max(start time) 
9 FROM dba optstat operations 
10 WHERE operation = 'gather database stats (auto)'); 
NAME VALUE 
block sample FALSE 
Cascade NULL 
concurrent FALSE 
degree NULL 
estimate percent DEFAULT_ESTIMATE PERCENT 
granularity DEFAULT_ GRANULARITY 
method_opt DEFAULT_METHOD OPT 
no_invalidate DBMS_STATS.AUTO INVALIDATE 
reporting mode FALSE 


stattype DATA 
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要 知道 日 志 信 息 是 使 用 与 之 前 描述 的 统计 信息 历史 相同 的 机 制 来 清除 的 。 因 此 ,两 者 拥有 相同 的 
保留 期 。 


8.15 保持 对 象 统计 信息 为 最 新 的 策略 


dbms_stats 包 为 管理 对 象 统计 信息 提供 了 很 多 特性 。 问 题 是 ， 应 该 如 何以 及 何 时 使 用 它们 来 实现 
一 个 成 功 的 配置 ? 这 个 问题 很 难 回 答 。 惑 伯 不 存在 绝对 的 答案 。 换 名 话说 ， 没 有 一 个 单独 的 方法 能 够 
适用 于 所 有 的 情况 。 我 们 来 研究 一 下 如 何 处 理 这 个 问题 。 

基本 的 原则 ， 也 可 能 是 最 重要 的 一 条 ， 就 是 查询 优化 器 需要 对 象 统计 信息 来 描述 存储 在 数据 库 中 
的 数据 。 因 此 当 数据 变 化 时 ， 对 象 统计 信息 也 应 该 跟着 变化 。 你 可 能 也 清楚 ， 我 是 提倡 定期 收集 对 象 
统计 信息 的 。 那 些 反 对 这 项 实践 的 人 会 争论 说 ， 如 果 一 个 数据 库 运 行 良 好 ， 就 没有 必要 重新 收集 对 象 
统计 信息 。 这 种 方法 的 问题 通常 是 ,一些 对 象 统计 信息 依赖 于 真实 的 数据 。 例 如 ， 有 这 样 一 种 统计 信 
息 ， 其 经 常 变化 的 是 那些 包含 数据 ( 比如 与 某 个 交易 、 某 个 销售 或 某 个 电话 相关 联 的 时 间 戳 ) 的 列 的 
低 / 高 值 。 诚 然 , 在 一 般 的 表 中 它们 的 变化 占 少数 , 但 是 通常 变化 的 那 部 分 很 关键 ， 因 为 它们 会 在 应 用 
程序 中 被 反复 使 用 。 在 实践 中 , 我 遇 到 过 的 由 于 没有 最 新 的 对 象 统计 信息 而 导致 的 问题 比 反 过 来 的 情 
况 要 多 得 多 。 

显而易见 ， 在 永远 不 变 的 数据 上 收集 对 象 统计 信息 毫 无 意义 。 只 有 陈旧 的 对 象 统计 信息 应 该 被 重 
新 收集 。 因 此 ,利用 记录 出 现在 每 张 表 上 的 修改 数量 的 特性 就 显得 必 不 可 少 。 用 这 种 方法 ， 你 可 以 只 
对 那些 经 历 了 大 量 修改 的 表 重 新 收集 统计 信息 。 默 认 情 况 下 ， 当 一 张 表 有 超过 10% 的 数据 发 生 了 变化 
就 被 认为 是 陈旧 的 。 这 是 个 合理 的 默认 值 。 从 11.1 版 本 开始 ， 如 果 有 必要 可 以 修改 这 个 默认 值 。 

收集 对 象 统计 信息 的 频率 也 是 一 个 存在 不 同 看 法 的 问题 。 我 见 过 各 种 成 功 的 案例 ， 有 按 小 时 的 ， 
有 按 月 的 ， 甚 至 有 更 低频 率 的 。 这 其 实 依赖 于 你 的 数据 。 无 论 如 何 ， 当 使 用 表 的 陈旧 属性 作为 重新 收 
集 对 象 统计 信息 的 基础 时 , 太 长 的 间隔 会 导致 过 量 的 陈旧 对 象 出 现 ， 而 太 短 的 间隔 又 会 导致 统计 信息 
收集 需要 过 多 的 时 间 以 及 资源 使 用 出 现 高 峰 。 为 此 ， 我 喜欢 将 它们 安排 得 更 频繁 ( 为 了 分 散 负载 ) 并 
保持 单一 的 运行 时 间 尽 可 能 地 短 。 如 果 你 的 系统 有 每 天 或 每 周 的 低 使 用 率 时 段 ， 那 么 将 收集 安排 在 那 
些 时 间 段 通常 是 一 个 好 主意 。 如 果 你 的 系统 是 一 个 真正 的 7x 24 系 统 ， 那 通常 更 好 的 做 法 是 尽 可 能 使 
用 非常 频繁 的 调度 ( 每 天 执行 许多 次 ) 来 分 散 负载 并 避 开 高 峰 期 。 

如 果 你 有 加 载 或 修改 大 量 数据 的 作业 ( 例如 , 在 数据 仓库 环境 中 的 ETL 作 业 ), 就 不 应 该 等 候 一 个 
已 安排 的 对 象 统计 信息 的 收集 完成 。 而 要 直接 将 要 修改 的 对 象 的 统计 信息 收集 作为 作业 本 身 的 一 部 
分 。 换 名 话说 ， 如 果 你 知道 某 些 事物 发 生 了 大 量变 化 ， 应 立即 触发 统计 信息 的 收集 。 

如 果 出 于 某 个 原因 ， 你 觉得 不 应 该 在 某 些 表 上 收集 对 象 统计 信息 ， 那 就 锁定 它们 。 这 样 的 话 ， 定 
期 收集 对 象 统计 信息 的 作业 就 会 直接 跳 过 这 些 表 。 这 比 完全 禁止 整个 数据 库 的 作业 活动 要 好 得 多 。 

应 该 尽 可 能 多 地 利用 默认 的 收集 作业 。 要 在 这 方面 满足 你 的 要 求 ， 你 应 该 检查 默认 的 配置 ， 如 果 
有 必要 则 进行 更 改 。 因 为 在 对 象 级 别 的 配置 仅 从 11.1 版 本 开始 才 可 用 ， 如 果 在 之 前 的 版 本 中 对 某 些 表 
有 特别 的 需求 ,应 该 在 默认 作业 之 前 安排 一 个 作业 来 处 理 它们 。 通 过 这 种 方式 ， 只 会 处 理 拥有 陈旧 统 
计 信 息 对 象 的 默认 作业 ， 而 会 直接 跳 过 已 处 理 的 表 。 锁 定 可 能 也 会 有 助 于 确保 仅 特 定 作 业 才 会 在 那些 
关键 表 上 重新 收集 对 象 统计 信息 。 

相反 ， 如 果 你 正在 考虑 完全 禁止 默认 的 收集 作业 ， 则 应 该 为 oracle 设 置 autostats_target 首 选项 。 
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那样 的 话 ， 就 让 数据 库 引 擎 处 理 好 数据 字典 ， 而 对 于 其 他 的 表 ， 可 以 设置 一 个 具体 的 作业 来 完成 你 所 
期 望 的 工作 。 

如 果 收 集 的 统计 信息 导致 无 效率 的 执行 计划 ,那么 你 可 以 做 两 件 事 。 第 一 是 通过 还 原本 次 收集 统 
计 信 息 之 前 顺利 使 用 的 对 象 统计 信息 来 修复 问题 。 第 二 是 找 出 为 什么 查询 优化 器 使 用 新 的 对 象 统计 信 
息 会 生成 无 效率 的 执行 计划 。 为 此 ， 你 首先 应 该 检查 最 近 收 集 的 统计 信息 是 否 正确 地 描述 了 数据 。 举 
例 来 说 ， 有 可 能 伴随 着 新 的 数据 分 布 的 采样 会 导致 不 同 的 直方 图 。 如 果 对 象 统计 信息 不 良 ， 那 么 收集 
本 身 ， 或 者 收集 使 用 的 参数 就 是 问题 所 在 。 如 果实 际 上 对 象 统计 信息 没有 问题 ,那么 还 有 两 种 可 能 的 
原因 。 要 么 是 查询 优化 器 没有 正确 配置 ， 要 么 是 查询 优化 器 犯 了 错误 。 你 几乎 无 法 控制 后 者 ， 但 是 应 
该 能 够 为 前 者 找到 解决 方案 。 无 论 如 何 ， 应 该 避免 匆忙 认定 是 收集 对 象 统计 信息 的 固有 问题 ， 而 因此 
停止 定期 收集 它们 。 

最 佳 实践 是 使 用 dbms_stats 包 收集 对 象 统计 信息 。 但 是 ， 确 实 存在 正确 的 对 象 统 计 信 息 误 导 查 询 
优化 器 的 情况 。 一 个 常见 的 例子 是 历史 数据 必须 保持 在 线 很 长 时 间 ( 举 个 例子 ,在 瑞士 某 些 类 型 的 数 
据 必须 至 少 保存 十 年 )。 在 这 种 情况 下 ,如 果 数 据 分 布 几乎 不 随 着 时 间 发 生 改 变 , 通过 dbms_stats 包 收 
集 的 对 象 统计 信息 应 该 没有 问题 。 与 此 相反 ， 如 果 数 据 分 布 严重 依赖 于 时 间 段 而 且 应 用 程序 经 常 只 访 
问 数据 的 一 部 分 ， 那 么 就 有 理由 手工 修改 〈 也 就 是 ， 捏 造 ) 对 象 统计 信息 用 以 描述 大 部 分 相关 数据 ， 
换 句 话说， 如 果 你 知道 dbms_stats 包 忽略 的 或 者 无 法 发 现 的 某 些 东 西 ， 那 么 就 可 以 合理 使 用 捏造 的 对 
象 统 计 信 息 来 告知 查询 优化 器 。 


8.16 小结 


本 章 描 述 了 什么 是 表 统计 信息 、 列 统计 信息 、 直 方 图 和 索引 统计 信息 ， 并 依次 说 明 它们 是 如 何 描 
述 存储 在 数据 库 中 的 数据 的 。 本 章 还 涵盖 了 如 何 使 用 dbms_stats 包 收集 对 象 统计 信息 以 及 在 数据 字典 
中 从 哪里 找到 它们 。 

本 章 没 有 详细 描述 对 象 统 计 信 息 的 使 用 。 相 关内 容 以 及 配置 查询 优化 器 的 初始 化 参数 信息 会 在 下 
一 章 进行 介绍 。 学 习 完 第 9 章 ， 你 应 该 能 够 正确 地 配置 查询 优化 器 ， 并 且 会 在 大 部 分 时 间 里 得 到 高 效 
的 执行 计划 。 
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配置 查询 优化 器 


查询 优化 器 对 SQL 语句 的 性 能 负 有 直接 责任 。 基 于 这 个 原因 , 我 们 有 必要 花 一 些 时 间 将 它 配 置 好 。 
事实 上 ， 并 不 存在 一 个 最 优化 的 配置 ,查询 优化 器 可 能 会 产生 低 效率 的 执行 计划 ， 从 而 导致 不 理想 的 
查询 优化 需 的 配置 不 仅仅 由 几 个 初始 化 参数 组 成 ， 还 包括 系统 统计 信息 和 对 象 统计 信息 ( 参见 第 
7 章 、 第 8 章 )。 本 章 将 描述 这 些 初 始 化 参数 和 统计 信息 如 何 影响 查询 优化 器 ， 并 展示 一 个 简单 实用 的 
路 线 图 以 帮助 你 获得 合理 的 配置 。 
警告 除了 一 个 公式 之 外 ，Oracle 没 有 公布 本 章 所 提供 的 其 他 公式 。 一些 测试 表明 这 些 公式 能 够 描述 
查询 优化 器 是 如 何 估 算 一 个 给 定 操 作 的 成 本 的 。 但 无 论 如 何 ， 也 不 能 说 在 所 有 情形 中 它们 都 
是 精确 的 或 者 正确 的 。 之 所 以 提供 它们 是 为 了 给 你 一 个 思路 ， 让 你 了 解 初始 化 参数 或 统计 信 
息 是 如 何 影 响 查 询 优 化 器 估算 的 。 


9.1 配置 还 是 不 配置 


鉴于 我 们 的 情况 ， 正 像 一 句 肯尼亚 谚语 说 的 那样 ， 我 会 说 :“ 配 置 查询 优化 器 代价 高 昂 ， 但 是 却 
值得 。” 在 实践 中 ,我 见 过 太 多 低估 了 一 个 良好 配置 的 重要 性 的 站 点 。 有 时 我 甚至 会 与 那些 对 我 说 出 
下 面 这 样 的 话 的 人 进行 激烈 讨论 :“ 我 们 不 需要 花费 时 间 为 每 一 个 数据 库 单独 配置 查询 优化 器 。 我 们 
已 经 有 一 组 在 所 有 数据 库 中 使 用 了 无 数 次 的 初始 化 参数 。” 首先, 我 会 这 样 回答 :“ 如 果 一 组 单独 的 参 
数 就 可 以 在 所 有 数据 库 中 运行 良好 ， 为 什么 Oracle 还 引入 了 将 近 二 十 几 个 专门 针对 于 查询 优化 器 的 初 
始 化 参数 ? 它们 很 擅长 自己 所 做 的 工作 。 如 果 存 在 这 样 的 一 个 神奇 的 配置 ,它们 会 默认 提供 它 并 隐藏 
相关 的 初始 化 参数 。” 接 下 来 我 会 仔细 地 通过 以 下 两 个 理由 来 解释 所 谓 的 神奇 配置 并 不 存在 。 

口 每 个 应 用 程序 都 有 自己 独特 的 需求 和 负载 情况 。 

口 每 个 系统 都 由 不 同 的 硬件 和 软件 组 件 组 成 ， 这 些 组 件 都 拥有 其 自己 的 特征 。 

如 果 查 询 优化 器 工作 良好 ， 就 意味 着 它 会 为 大 部 分 "SQL 语句 生成 合理 的 执行 计划 。 但 还 要 注意 ， 


肯尼亚 谚语 的 原文 是 “Peace is costly, but it is worth the expense"”， 意 思 是 “和 平 的 代价 高 昂 ， 但 是 却 值得 "。 详 情 
请 参见 http:Wwww.quotationspage.com/quote/38863.html。 

名 与 其 他 任何 你 能 想象 到 的 活动 一 样 ， 十 全 十 美 在 软件 开发 中 也 是 无 法 实现 的 。 这 条 规则 ， 即 使 你 和 Oracle 都 不 嘉 
欢 ， 也 会 适用 于 查询 优化 器 。 因 此 你 应 该 预料 到 会 有 一 小 部 分 的 SQL 语句 需要 手工 介入 ( 详 见 第 11 章 ), 
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因为 只 有 在 正确 配置 了 查询 优化 器 ,并 且 数 据 库 被 设计 成 能 够 利用 它 的 全 部 特性 的 条 件 下 ， 上 面 的 话 
才 成 立 。 这 一 点 再 怎么 强调 都 不 过 分 。 还 要 注意 查询 优化 器 的 配置 不 仅 包含 初始 化 参数 ， 而 且 包括 系 
统统 计 信 息 和 对 象 统 计 信息 。 


9.2 配置 路 线 图 


因为 不 存在 类 似 神奇 配置 这 样 的 事情 , 我 们 需要 一 个 可 靠 的 、 可 信 的 规程 来 帮助 我 们 。 图 9-1 总 结 
了 我 所 使 用 的 主要 步骤 。 它 们 的 描述 如 下 所 示 。 


1) optimizer_mode 
db_file_multiblock_read_count 


optimizer_features_enable 
optimizer_secuyre_view_merging 
optimizer_adaptive features 
optimizer_adaptive_reporting_only 
query_rewrite_enabled 
query_rewrite_integrity 
star_transformation_enabled 


bd 收集 系统 统计 信息 
收集 对 象 统计 信息 


workarea_size_policy = auto < 会 注 workarea_size_policy = manual 


hash_area_size 
sort_area_size 
sort_area_retained_size 
bitmap_merge_area_size 


pga_aggregate_target 
pga_aggregate_limit 


测试 应 用 程序 


大 多 数 执行 计划 
是 高 效 的 


optimizer_index_caching 
optimizer_index_cost_adj 
optimizer_dynamic_sampling 
调整 直方 图 
定义 扩展 的 统计 信息 


并 


图 9-1 配置 路 线 图 的 主要 步骤 


(1) 有 两 个 初始 化 参数 需要 不 断 调整 : ptimizer mode 和 db file multiblock read_ count。 稍 后 你 会 
看 到 ， 后 者 并 不 总 是 与 查询 优化 器 本 身 直 接 相 关 。 然 而 ， 某 些 操作 的 性 能 可 能 会 极 大 地 依赖 于 它 - 
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(2) 因为 这 一 步 中 调整 的 初始 化 参数 的 默认 值 通常 来 说 工作 良好 ， 所 以 这 一 步 是 可 选 的 。 不 管 怎 
样 ， 这 一 步 的 目标 是 启用 或 禁用 查询 优化 器 的 专项 特性 。 

(3) 因为 系统 统计 信息 和 对 象 统计 信息 为 查询 优化 器 提供 至 关 重 要 的 信息 , 所 以 必须 要 收集 它们 。 

(4) 通过 设置 workarea_size_policy 初 始 化 参数 ， 可 以 选择 手工 还 是 自动 调整 在 内 存 中 存储 数据 
操作 的 工作 区 大 小 。 根 据 不 同 的 选择 方法 ， 其 他 的 初始 化 参数 可 以 在 第 5 步 或 第 6 步 中 进行 设置 。 

(5) 如 果 调 整 工作 区 大 小 是 自动 的 ， 则 设置 pga_aggregate _target 初 始 化 参数 。 另 外 ， 从 12.1 版 本 
开始 ， 同 时 还 可 以 修改 pga_aggregate_limit 初 始 化 参数 。 

(6) 如 果 调 整 工 作 区 大 小 是 手动 的 ， 实 际 大 小 取决 于 使 用 内 存 的 操作 的 类 型 。 基 本 上 ， 每 种 类 型 
的 操作 都 有 一 个 具体 的 参数 。 

(7) 当 第 一 部 分 的 配置 就 位 时 ， 就 该 测试 应 用 程序 了 。 在 测试 过 程 中 ， 没 有 提供 需求 性 能 的 组 件 
的 执行 计划 被 收集 起 来 。 通 过 分 析 这 些 执行 计划 ， 你 应 该 能 够 推断 出 问题 所 在 。 注 意 在 这 一 阶段 , 重 
点 是 识别 出 普遍 行为 ， 而 非 个 例 行 为 。 举 例 来 说 ， 你 可 能 注意 到 查询 优化 器 使 用 过 多 或 过 少 的 索引 或 
者 没有 正确 识别 限制 条 件 。 

(8) 如 果 查 询 优化 器 能 够 为 大 部 分 SQL 语句 生成 高 效率 的 执行 计划 ， 那 表明 配置 良好 。 如 果 不 能 ， 
继续 进行 步骤 9。 

(9) 如 果 查 询 优化 器 趋向 于 使 用 过 多 或 者 过 少 的 索引 或 嵌 套 循环 ， 通 常 可 以 通过 调整 初始 化 参数 
optimizer index_caching 和 optimizer index_cost_ adj 来 修复 这 个 问题 。 如 果 查 询 优化 器 在 估算 基数 方 
面 出 现 重大 错误 ， 可 能 是 因为 一 些 直 方 图 缺失 或 者 需要 调整 。 调 整 动态 采样 也 可 能 会 有 帮助 。 从 11.1 
版 本 开始 ， 扩 展 的 统计 信息 也 可 能 有 所 帮助 。 

根据 图 9-1， 步 又 1~6 中 设置 的 初始 化 参数 不 能 在 事后 进行 修改 。 当 然 了 ， 这 也 不 是 一 成 不 变 的 。 
如 果 你 无 法 通过 调整 与 索引 相关 的 初始 化 参数 或 步 又 9 中 的 直方 图 来 获得 理想 的 结果 ， 可 能 有 必要 从 
头 来 过 。 还 有 必要 提 一 下 ， 因 为 有 几 个 初始 化 参数 对 系统 统计 信息 有 影响 ， 在 更 改 完 它 们 之 后 ， 可 能 
有 必要 重新 计算 系统 统计 信息 。 
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显然 Oracle 并 不 只 是 随机 提供 新 的 初始 化 参数 。 相 反 ， 引 入 的 每 个 初始 化 参数 都 是 为 了 控制 查询 
优化 器 的 某 一 特性 或 者 行为 。 尽 管 有 重复 的 嫌疑 ， 我 还 是 要 提醒 你 Oracle 对 于 新 参数 的 引进 意味 着 没 
有 一 个 单独 的 值 能 够 适用 于 所 用 情况 。 因 此 ， 对 于 每 一 个 初始 化 参数 ,必须 通过 应 用 程序 负载 情况 和 
数据 库 引 擎 运行 的 系统 共同 推断 出 一 个 合理 的 取 值 。 

要 为 查询 优化 器 执行 一 个 成 功 的 配置 ,重要 的 是 要 理解 它 是 如 何 运作 的 ， 以 及 每 个 初始 化 参数 对 
它 的 影响 。 有 了 这 个 认识 ， 就 不 要 随意 对 配置 作 调整 ， 也 不 要 从 最 近 在 网 上 找到 的 文章 中 复制 “理想 
的 值 ” ， 而 应 该 从 以 下 方面 着 手 。 

口 充分 了 解 现状 。 举 例 来 讲 ， 为 什么 查询 优化 器 选择 了 一 个 非 最 优 的 执行 计划 ? 

口 决定 要 实现 的 目标 。 换 句 话说， 你 要 获得 什么 样 的 执行 计划 ? 

口 找 出 有 哪些 初始 化 参数 或 者 统计 信息 应 该 进行 调整 以 达到 你 设置 的 目标 。 当 然 ， 在 某 些 情况 

下 仅仅 设置 初始 化 参数 是 不 够 的 。 可 能 有 必要 修改 SQL 语句 或 者 数据 库 设 计 。 
下 面 的 小 节 将 会 描述 图 9-1 中 配置 路 线 图 引用 的 一 些 初始 化 参数 如 何 运作 ,并 给 出 关于 如 何 为 你 的 
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系统 找 出 合理 取 值 的 建议 。 本 章 没 有 描述 的 参数 会 在 本 书 其 他 地 方 讲述 这 些 参数 所 控制 的 特性 时 进行 
介绍 。 参 数 可 分 成 两 组 : 一 组 参数 只 影响 查询 优化 器 的 操作 ， 另 一 组 则 与 程序 全 局 区 ( PGA ) 有 关 。 


9.3.1 查询 优化 器 参数 
接 下 来 介绍 几 个 与 查询 优化 器 的 操作 有 关 的 参数 。 


1. optimizer mode 

optimizer_mode 这 个 参数 至 关 重 要 ， 因 为 通过 它 可 以 向 查询 优化 器 指明 “高 效率 ”这 个 词 的 含义 。 
通常 来 讲 ， 它 的 意思 可 能 是 “更 快 一 些 ”“ 使 用 更 少 的 资源 ”或 者 其 他 的 意思 。 因 为 在 使 用 数据 库 处 
理 数据 时 ， 通 常 希 望 处 理 速度 越 快 越 好 。 因 此 ， 高 效 的 含义 应 该 是 “用 最 快 的 方式 执行 SQL 语句 而 不 
浪费 不 必要 的 资源 "。 这 对 于 总 是 完全 执行 的 SQL 语句 没有 问题 ( 例如 ，INSERT 语 句 )。 而 另 一 方面 ， 
对 于 查询 ， 则 会 有 细微 的 差异 。 比 如 说 ， 应 用 程序 并 不 是 必须 要 获取 查询 返回 的 所 有 行 。 换 句 话说 ， 
查询 可 能 是 部 分 执行 的 。 

举 一 个 与 Oracle Database 无 关 的 例子 。 当 我 用 谷歌 搜索 “查询 优化 器 ”时 ， 会 获得 最 佳 排名 的 匹 
配 页 ， 首 页 列 出 了 前 十 个 结果 (十 个 最 佳 结果 )。 在 同一 个 页 面 上 ， 还 会 显示 一 条 通知 消息 : 在 结果 
集中 有 986 000 个 页 面 ， 并 且 搜 索 它 们 花费 了 0.26 秒 。 这 是 一 个 优化 处 理 流 程 以 尽 可 能 快速 地 返回 初始 
数据 的 例子 ， 因 为 最 前 面 的 几 页 几乎 总 是 用 户 唯一 真正 会 去 访问 的 页 面 。 为 了 访问 其 中 的 一 页 ， 接 下 
来 我 单 击 对 应 的 链接 。 这 时 ,我 通常 对 于 仅 获取 前 几 行 内 容 不 感 兴趣 。 我 希望 整个 页 面 都 可 以 访问 并 
且 正 确 排版 ,也 就 是 说 我 会 开始 阅读 。 在 这 种 情况 下 ， 处理 流程 应 该 被 优化 为 尽快 提供 所 有 数据 而 非 
一 小 部 分 。 每 一 个 应 用 程序 ( 或 程序 的 一 部 分 ) 都 会 归结 为 以 下 两 种 策略 : 要 么 是 优先 快速 传递 结果 
集中 最 靠 前 的 数据 ， 要 么 是 优先 快速 传递 整个 结果 集 ( 这 其 实 等 同 于 快速 传递 结果 集 的 最 后 一 行 )。 

要 为 optimizer_mode 初 始 化 参数 选择 合适 的 值 ， 应 该 首先 问 自己 一 个 问题 是 让 查询 优化 器 产生 
快速 返回 首 行 数据 的 执行 计划 更 重要 ， 还 是 快速 返回 未 行 数据 的 执行 计划 更 重要 。 

口 如 果 快 速 返 回 末 行 数据 更 重要 ， 应 该 使 用 值 311_ rows 。 这 是 最 常用 的 配置 。 

口 如 果 快 速 返回 首 行 数 据 更 重要 ， 应 该 使 用 值 first_rows 7 (7 的 取 值 为 1、10、100 或 1000 )。 这 

个 配置 应 该 只 在 应 用 程序 部 分 获取 的 结果 集 大 于 该 参数 指定 的 行 数 时 才 被 使 用 。 对 于 已 经 
在 的 应 用 程序 ， 可 以 通过 比较 执行 和 v$sqlarea 视 图 中 的 end_of_fetch_count 列 来 检查 这 一 点 。 
注意 更 早期 的 首 行 优化 器 实现 ( 也 就 是 ， 通 过 值 first_rows 进 行 配 置 ) 不 应 该 再 被 使 用 了 。 事 
实 上 ， 提 供 这 个 值 仅 是 为 了 向 后 兼容 。 

默认 值 是 all rows。 还 要 注意 INSERT、DELETE 、MERGE 和 UPDATE 语 句 总 是 使 用 all rows 来 优化 。 这 
样 做 是 很 有 道理 的 ， 因 为 这 些 SQL 语句 必须 在 将 控制 权 交还 给 调用 者 之 前 处 理 所 有 的 数据 。 


警告 首 行 最 优化 的 关键 思想 是 避免 阻塞 操作 ( 也 就 是 说 ， 直 到 运行 完毕 之 前 不 会 产生 任何 数据 的 
操作 )， 为 此 ， 通 常 更 倾向 于 嵌 套 循环 连接 而 非 散 列 连接 ( 直到 散 列 表 建 立 起 来 之 前 都 是 阻塞 
状态 ) 或 合并 连接 ( 直到 两 个 输入 都 完成 排序 之 前 都 是 阻塞 状态 ), 此外, 在 某 些 情形 中 ，ORDER 
BY 操作 ( 直到 数据 被 完成 排序 之 前 都 是 阻塞 状态 ) 会 由 索引 范围 扫描 取代 。 对 于 大 的 结果 集 ， 
首 行 优化 未 必 能 够 带 来 最 优 的 性 能 表现 。 所 以 ， 最 重要 的 是 ， 只 有 在 调用 的 应 用 程序 只 抓 取 
大 结果 集 的 一 部 分 时 才 使 用 首 行 优化 。 
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optimizer_mode 初 始 化 参数 是 动态 的 , 并 且 可 以 在 实例 和 会 话 级 别 修改 。 在 12.1 多 租户 环境 下 , 也 
可 以 在 PDB 级 别 设置 它 。 此 外 ， 通 过 下 面 其 中 一 种 hint， 也 可 以 在 语句 级 别 设置 它 : 
口 all rows; 


口 rst_rows(n)，n 是 大 于 0 的 任何 自然 数 。 


2. optimizer features enable 

在 每 个 数据 库 版 本 中 ，Oracle 都 会 在 查询 优化 器 中 引入 或 启用 新 的 特性 。 如 果 正 在 升级 到 一 个 新 
的 数据 库 版 本 并 希望 保留 查询 优化 器 旧 的 行为 ， 可 以 通过 将 optimizer features_enable 初 始 化 参数 设 
秆 为 升级 之 前 的 数据 库 版 本 来 实现 。 遗 憾 的 是 ， 并 不 是 所 有 的 新 特性 都 可 以 通过 这 个 初始 化 参数 来 禁 
用 。 举例 来 说 ,如果 你 在 11.2 版 本 中 将 其 设置 为 10.2.0.4， 就 不 会 获得 与 10.2.0.4 版 本 完全 一 样 的 查询 优 
化 器 。 出 于 这 个 原因 , 我 通常 建议 使 用 默认 值 , 也 就 是 与 数据 库 可 执行 文件 使 用 相同 的 版 本 号 。 另 外， 
Oracle Support 文 档 Use Caution if Changing the OPTIMIZER_FEATURES ENABLE Parameter After an 
Upgrade( 1362332.1 ) 也 提供 了 类 似 建议 。 


提示 “改变 optimizer features_enable 初 始 化 参数 的 默认 值 只 是 短期 解决 方案 .迟早 应 用 程序 都 应 该 
适应 (尽量 充分 利用 ) 新 的 数据 库 版 本 。 


optimizer features_enable 初 始 化 参数 合法 的 值 是 类 似 10.2.0.5、11.1.0.7 或 11.2.0.3 这 样 的 数据 库 
版 本 号 。 因 为 并 不 会 针对 这 个 参数 的 补丁 级 别 更 新 文档 ( 特别 是 Oracle Database Reference 手 册 )， 所 
以 可 以 通过 以 下 SQL 语 句 来 生成 支持 的 值 : 

SOL> SELECT value 


2 FROM v$parameter valid _ values 
3 WHERE name = "optimizer features enable'; 


外 区 
了 .203 
da2a0s 3 t 


optimizer_features_enable 初 始 化 参数 是 动态 的 ， 并 且 可 以 在 实例 和 会 话 级 别 修 改 。 在 12.1 多 租 
户 环 境 下 ， 也 可 以 在 PDB 级 别 设置 它 。 此 外 ， 也 可 以 在 语句 级 别 通 过 optimizer features_enable 这 个 
hint 来 设置 一 个 值 。 下 面 的 两 个 例子 分 别 通过 这 个 hint 设 置 默 认 值 和 一 个 具体 值 (有关 hint 的 详细 内 容 
请 参见 第 11 章 ): 

口 optimizer features enable(default) 

口 optimizer features enable('10.2.0.5') 


3. db file multiblock read count 
数据 库 引 擎 在 多 块 读 取 期 间 ( 例如 ， 全 表 扫 描 或 索引 快速 全 扫描 ) 使 用 的 最 大 磁盘 LO 大 小 是 由 
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db_block_size 和 db_file_multiblock_read_count 初 始 化 参数 值 的 乘积 决定 的 。 因 此 ， 在 多 块 读 取 期 间 
读 取 的 最 大 块 数量 是 由 最 大 磁盘 IO 大 小 除 以 读 取 的 表 空 间 的 块 大 小 来 决定 的 。 换 名 话说, 对 于 默认 块 
大 小 ,db file multiblock_read count 初始 化 参数 指定 的 是 读 取 的 最 大 块 数量 。 这 里 仅 指 最 大 的 数量 
是 因为 ， 至 少 有 以 下 三 种 常见 情况 会 导致 多 块 读 取 的 数量 要 小 于 该 初始 化 参数 指定 的 值 。 

口 对 于 段 头 块 和 其 他 只 包含 像 扩展 映射 这 样 的 段 元 数据 的 块 ， 都 是 通过 单 块 读 取 的 。 

口 物理 读 从 来 不 会 横 跨 多 个 扩展 ， 但 有 一 个 例外 ， 就 是 针对 使 用 自动 段 空 间 管理 的 表 空 间 执行 

直接 路 径 读 。 

口 已 经 在 缓冲 区 中 的 数据 块 ， 除 非 是 直接 路 径 读 ， 和 否则 不 会 从 磁盘 IO 子 系统 重新 读 取 。 

举例 说 明 ， 图 9-2 展 示 了 在 使 用 手工 段 空间 管理 的 表 空 间 中 存储 的 段 的 结构 。 与 其 他 任何 段 一 样 ， 
它 由 扩展 组 成 (在 本 例 中 有 2 个 )， 每 一 个 扩展 都 是 由 块 组 成 的 〈 在 本 例 中 有 16 个 )。 第 一 个 扩展 的 第 
一 个 块 是 段 头 。 某 些 块 (4、9、10、19 和 21 ) 已 经 缓存 在 缓冲 区 中 。 为 这 个 段 执行 缓冲 读 的 数据 库 引 
擎 进程 无 法 执行 任何 的 物理 多 块 读 ， 即 使 db file multiblock_read_count 初 始 化 参数 设置 为 大 于 或 等 
于 32 的 值 也 不 行 。 


1 四 中 Da 
本 四 四 四 四 四 四 


ml 
回回 回国 加 回回 上 加 | 


图 9-2 ”数据 段 的 结构 


如 果 将 db file multiblock read count 初始 化 参数 设置 为 8， 则 会 执行 下 面 这些 缓 冲 读 。 
口 一 次 段 头 的 单 块 读 ( 块 1 )。 
口 一 次 两 个 块 的 多 块 读 ( 块 2 和 块 3 )。 因 为 块 4 已 经 缓存 所 以 无 法 读 取 更 多 的 块 。 
口 一 次 四 个 块 的 多 块 读 ( 从 块 5 到 块 8 )。 因 为 块 9 已 经 缓存 所 以 无 法 读 取 更 多 的 块 。 
口 一 次 六 个 块 的 多 块 读 ( 从 块 11 到 块 16 )。 因 为 块 16 是 该 扩展 的 最 后 一 个 块 ， 所 以 无 法 读 取 更 多 
的 块 。 
口 一 次 两 个 块 的 多 块 读 ( 块 17 和 块 18 )。 因 为 块 19 已 经 缓存 所 以 无 法 读 取 更 多 的 块 。 
口 一 次 块 20 的 单 块 读 。 因 为 块 21 已 经 缓存 所 以 无 法 读 取 更 多 的 块 。 
口 一 次 八 个 块 的 多 块 读 ( 从 块 22 到 块 29 )。 因 为 db file multiblock read_ count 初始 化 参数 被 设 
置 为 8&， 所 以 无 法 读 取 更 多 的 块 。 
一 次 三 个 块 的 多 块 读 ( 从 块 30 到 块 32 )。 
概括 起 来 ， 这 个 进程 执行 了 两 次 单 块 读 操作 和 6 次 多 块 读 操作 。 一 次 多 块 读 读 取 的 平均 块 数量 大 
概 是 4 个 。 平 均 大 小 小 于 8 的 事实 解释 了 为 何 Oracle 会 在 系统 统计 信息 中 引入 mbrc 值 。 
db_ file multiblock read_count 初 始 化 参数 是 动态 的 ,. 并 且 可 以 在 实例 和 会 话 级 别 修改 。 在 12.1 
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多 租户 环境 下 ， 也 可 以 在 PDB 级 别 设置 它 。 

这 时 候 ， 讨 论 一 下 查询 优化 器 是 如 何 计 算 多 块 读 操 作 〈 例 如， 全 表 扫 描 或 索引 快速 全 扫描 ) 的 成 
本 也 非常 重要 。 

当 有 负载 系统 统计 信息 可 用 时 ,IO 成 本 并 不 依赖 于 db file multiblock_ read count 初始 化 参数 的 
值 。 它 是 由 公式 9-1 计 算 而 来 。 注 意 ， 之 所 以 用 mreadtim 除 以 sreadtim 是 因为 查询 优化 器 根据 单 块 读 正 
常 化 了 成 本 ， 就 像 在 第 7 章 中 讨论 的 那样 (公式 7-2 )。 

公式 9-1 使 用 有 负载 统计 信息 时 多 块 读 操作 的 IO 成 本 


blocks mreadtim 


in_cost ~ 


mbrce sreadtim 


在 公式 9-1 中 ， 若 使 用 无 负载 统计 信息 ， 则 变量 会 蔡 换 成 以 下 值 。 

口 倘若 db file multiblock_read_count 初 始 化 参数 明确 设置 了 ， 则 mbrc 由 db_file multiblock_ 

read_count 初 始 化 参数 的 值 蔡 换 ;和 否则， 使 用 8 作为 值 。 

口 sreadtim 由 公式 7-3 计 算出 来 的 值 计算 。 

口 mreadtim 由 公式 7-4 计 算出 来 的 值 计 算 。 

这 意味 着 只 有 在 使 用 无 负载 统计 信息 时 ，db_file_multiblock_read_count 初 始 化 参数 才 会 对 多 块 
读 操 作 的 成 本 产生 直接 的 影响 这 还 意味 着 太 高 的 值 可 能 会 导致 过 多 的 全 表 扫 描 或 至 少 造成 对 多 块 读 
操作 成 本 的 低估 。 进 一 步 讲 ， 这 是 有 负载 统计 信息 优 于 无 负载 统计 信息 的 另 一 种 情况 。 

你 已 经 知道 了 成 本 公式 ， 现 在 需要 知道 如 何 找 出 db_file_multiblock_read count 初始化 参数 应 该 
设置 的 值 。 最 重要 的 是 要 认识 到 多 块 读 对 于 性 能 有 重大 影响 。 因 此 ， 要 小 心 设置 db_ file_ multiblock 
read count 初始 化 参数 的 值 以 达到 最 佳 性 能 。 虽 然 那些 能 够 引发 1 MB 磁盘 IO 大 小 的 值 通 常 提供 近乎 
最 好 的 性 能 , 但 有 时 高 一 些 或 低 一 些 的 值 会 更 好 。 此 外 , 更 高 的 值 通常 需要 更 少 的 CPU 来 处 理 磁盘 IO 
操作 ,在 不 同 的 参数 值 下 执行 一 个 简单 的 全 表 扫 描 , 可 以 给 出 关于 这 个 初始 化 参数 的 影响 的 有 用 信息 ， 
进而 帮助 我 们 找到 最 佳 值 。 下 面 的 PL/SQL 代 码 段 是 assess_dbfmbrc.sql 脚 本 的 一 段 摘 录 ， 可 以 用 于 此 
用 途 : 


BEGIN 
dbms_output.put line('dbfmbrc blocks seconds cpu'); 
FOR i IN 0..10 
LOOP 
1 dbfmbrc := power(2,i); 


EXECUTE IMMEDIATE 'ALTER SESSION SET db file multiblock read count = '||1 dbfmbrc; 
EXECUTE IMMEDIATE 'ALTER SYSTEM FLUSH BUFFER CACHE'; 


SELECT sum(decode(name, "physical reads', value)), 
sum(decode(name, "CPU used by this session', value)) 

INTO 1 starting blocks, 1 starting cpu 

FROM v$mystat ms JOIN v$statname USING (statistic#) 

WHERE name IN ('physical reads','CPU used by this session'); 


1 starting time := dbms utility.get time(); 


SELECT count(*) INTO 1 count FROM t; 
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1 ending time := dbms utility.get time(); 


SELECT sum(decode(name, 'physical reads', value)), 
sum(decode(name, 'CPU used by this session', value)) 

INTO 1 ending blocks, 1 ending cpu 

FROM v$mystat ms JOIN v$statname USING (statistic#) 

WHERE name IN ('physical reads','CPU used by this session'); 


1 time := round((l1 ending time-1_ starting time)/100,1); 
1 blocks := 1 ending blocks-1 starting blocks; 
1 cpu := 1 ending cpu-l] starting cpu; 
dbms output.put line(1 dbfmbrc||' “||1blocks|| ‘||to char(l time)|| '||to char(l cpu)); 
END LOOP; 
END; 


如 你 所 见 , 实现 起 来 也 没有 那么 难 。 无论 如 何 , 当心 不 要 在 操作 系统 和 磁盘 IO 子 系统 级 别 缓存 测 
试 表 ， 因 为 那样 会 导致 测试 失效 。 避 免 这 样 做 的 最 简单 方式 是 使 用 比 你 系统 中 可 用 的 最 大 缓冲 区 还 要 
大 的 表 。 对 于 预计 要 使 用 并 行 处 理 的 系统 ， 也 值得 去 扩展 这 样 的 一 个 测试 来 执行 并 行 查询 ( 详 见 第 15 
壮 访 

图 9-3 展 示 了 在 我 的 测试 系统 上 所 有 初始 化 参数 设置 为 默认 值 的 情况 下 , 针对 一 个 11.2 的 数据 库 执 
行 以 上 的 PL/SQL 代 码 块 测量 得 到 的 特征 值 。 下 面 是 需要 注意 的 特征 。 

口 吞吐 率 由 db file multiblock_read_count 取 较 小 值 时 的 200 MB/s 增 加 到 使 用 很 大 值 时 的 600 


MB/S。 
口 CPU 使 用 率 从 db _ file multiblock _ read_count 初 始 化 参数 取 较 小 值 时 的 1.5 秒 下 降 到 取 很 大 值 
时 的 0.5 秒 。 


吞吐 率 (MB/s) 
(5) 出 绸 NdD 


db_fle_multiblock_read_count 
多 否 叶 率 O CPU 使 用 


图 9-3 ”磁盘 IO 大 小 对 于 在 四 个 不 同 的 系统 上 执行 全 表 扫 描 的 性 能 的 影响 


也 可 以 让 数据 库 引 擎 自动 配置 db file multiblock read _ count 初始 化 参数 的 值 。 要 使 用 这 个 特性 ， 
只 需 不 设置 它 就 可 以 了 。 如 公式 9-2 所 示 ， 接 下 来 数据 库 引擎 就 会 尝试 将 其 设置 为 一 个 能 够 允许 1MB 
物理 读 的 值 。 然 而 ， 不 管 怎 样 ， 如 果 缓 冲 区 的 大 小 与 数据 库 支持 的 会 话 数量 相 比 非常 小 ， 就 会 应 用 某 
种 合理 性 检查 以 减 小 这 个 值 。 


9.3 设置 正确 的 参数 251 


公式 9-2 db file multiblock read count 初始 化 参数 的 默认 值 


db_ file_multibolck read count sjleast | oo | 
db_block size Sessio18g :dbD_ block size 

正如 之 前 描述 的 那样 ，1 MB 的 物理 读 并 不 总 是 最 佳 选择 , 所 以 建议 不 要 使 用 这 个 特性 。 最 好 能 够 
具体 问题 具体 分 析 以 找 出 最 合适 的 值 。 

要 知道 如 果 将 无 负载 统计 信息 与 这 个 自动 配置 一 起 使 用 ，mbrc 就 不 会 被 公式 9-1 自 动 配置 的 值 取 
代 ， 而 是 会 使 用 8 这 个 值 。 

4. optimizer dynamic sampling 

以 往 ， 查询 优 化 器 的 估算 只 依靠 存储 在 数据 字典 中 的 对 象 统计 信息 。 有 了 动态 采样 ， 情 况 就 不 一 
样 了 。 事 实 上 ， 在 解析 阶段 也 可 能 会 动态 收集 某 些 统计 信息 。 这 意味 着 要 收集 额外 的 信息 ， 会 针对 引 
用 的 对 象 执行 一 些 (采样 ) 查询 。 遗 憾 的 是 ， 由 动态 采样 收集 的 统计 信息 既 不 会 存储 在 数据 字典 中 ， 
也 不 会 存储 在 其 他 什么 地 方 。 事 实 上 重用 它们 的 唯一 方式 就 是 在 共享 游标 内 部 重用 它们 。 还 要 注意 由 
动态 采样 收集 的 技术 并 非 一 定 要 使 用 。 实 际 上 , 查询 优化 器 会 执行 一 些 合 理性 检查 来 决定 是 否 应 该 使 
用 它们 。 3 


注意 ” 自 12.1 版 本 开始 ,已 使 用 动态 统计 信息 ( dynamic statistics ) 取代 了 动态 采样 ， 在 本 书 中 我 总 是 
使 用 旧名 称 。 


optimizer_dynamic_sampling 初 始 化 参数 的 值 (也 叫 作 级 别 ) 指定 如 何以 及 何 时 使 用 动态 采样 。 表 9 
9-1 总 结 了 可 接受 的 值 和 它们 的 含义 。 注 意 其 默认 值 取决 于 optimizer features_enable 初 始 化 参数 。 

口 如 果 将 optimizer_features_enable 设 置 为 10.0.0 或 更 高 ， 默 认 值 为 级 别 2。 

口 如 果 将 optimizer features _ enable 设置 为 9.2.0， 默 认 值 为 级 别 1。 

口 如 果 将 optimizer features_enable 设 置 为 9.0.1 或 更 低 ， 则 禁用 动态 采样 。 


表 9-1 动态 采样 的 级 别 及 其 含义 


1 动态 采样 用 于 没有 对 象 统 计 信 息 的 表 。 但 是 ， 只 有 满足 以 下 三 个 条 件 时 才 会 发 生 : 表 上 没 “32 
有 索引 ， 它 是 连接 的 一 部 分 (也 可 以 是 子 查询 或 不 可 合并 视图 ) ， 并 且 该 表 在 高 水 位 线 以 
下 拥有 的 块 的 数量 要 比 动态 采样 需要 的 块 数量 多 
2 动态 采样 用 于 所 有 没有 对 象 统计 信息 的 表 64 
3 动态 采样 用 于 满足 级 别 2 标准 的 所 有 表 ， 此 外 ， 还 有 那些 推测 会 用 于 估算 谓词 选择 率 的 表 ”32 或 64 
4 动态 采样 用 于 满足 级 别 3 标 准 的 所 有 表 ， 此 外 ， 还 包括 在 WHERE 子 句 中 引用 两 个 或 两 个 以 上 32 或 64 


列 的 表 
5 同 级 别 4 64 
6 同 级 别 4 128 


7 同 级 别 4 256 
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( 续 ) 
级 别 什么 时 候 使 用 动态 采样 块 的 数量 
8 级 4 
9 同 级 别 4 4096 
10 同 级 别 4 所 有 的 块 
11 查询 优化 器 决定 何 时 以 及 如 何 使 用 动态 采样 。 此 级 别 从 11.2.0.4 版 本 开始 才 可 用 自动 决定 


# 这 是 当 动态 采样 通过 初始 化 参数 或 在 语句 级 别 的 语法 中 使 用 hint 触 发 时 用 于 采样 的 块 的 数量 。 对 于 级 别 3 和 级 别 4， 如 果 
对 象 统 计 信息 可 用 ， 则 抽取 32 个 块 ; 否则 ， 抽 取 64 个 块 。 当 在 对 象 级 别 的 语法 中 使 用 hint 的 时 候 ， 以 及 对 于 从 1 到 9 的 级 
别 ， 块 的 数量 是 用 下 面 的 公式 计算 出 来 的 : 32 24 中， 


optimizer dynamic_sampling 初 始 化 参数 是 动态 的 ， 并 且 可 以 在 实例 级 别 以 及 会 话 级 别 进行 修改 。 
在 12.1 多 租户 环境 下 ， 也 可 以 在 PDB 级 别 进行 设置 。 此 外 ， 也 可 以 通过 hintdynamic_sampling 在 语句 级 
别 指定 一 个 值 。 这 个 hint 支 持 以 下 两 种 语法 。 

口 语句 级 别 的 语法 覆盖 optimizer dynamic sampling 初 始 化 参数 的 值 : dynamic sampling(level)。 

口 对 象 级 别 的 语法 只 为 特定 的 表 触 发 动态 采样 : dynamic_sampling(table alias level)。 


警告 ”在 对 象 级 别 语法 中 通过 使 用 hint 触 发 动态 采样 时 ， 采 样 总 是 会 发 生 。 换 句 话 说， 查询 优化 器 不 
去 检查 是 否 满足 在 表 9-1 中 提 到 的 规则 。 但 是 ， 根 据 对 象 统 计 信 息 是 否 已 经 可 用 ， 采 样 的 统计 
信息 可 能 会 被 委 弃 掉 。 所 有 这 些 可 能 都 是 不 必要 的 间接 开支 ， 所 以 我 不 推荐 使 用 对 象 级 别 的 
语法 。 


从 11.2 版 本 开始 ， 如 果 将 optimizer dynamic _ sampling 初 始 化 参数 设置 为 默认 值 ， 则 由 查询 优化 器 
自动 决定 如 何以 及 何 时 将 动态 采样 用 于 并 行 执行 的 SQL 看 句 中 。 这 样 做 是 因为 并 行 SQL 语句 可 能 会 消 
耗 大 量 的 资源 ， 因 此 ， 为 其 获得 尽 可 能 好 的 执行 计划 非常 关键 。 

查询 优化 器 可 以 使 用 动态 采样 收集 两 种 类 型 的 统计 信息 。 第 一 种 类 型 包含 以 下 几 个 方面 : 

口 一 个 段 高 水 位 线 以 下 的 块 的 数量 

口 一 张 表 中 行 的 数量 

口 一 个 列 中 唯一 值 的 数量 

口 一 个 列 中 空 值 的 数量 

正如 你 所 看 到 的 ， 第 一 种 类 型 的 统计 信息 等 同 于 在 数据 字典 中 应 该 已 经 可 用 的 对 应 的 统计 信息 
因此 ， 动 态 采样 收集 的 统计 信息 只 有 在 对 象 统计 信息 缺失 或 不 准确 ( 陈旧 ) 的 条 件 下 才 有 意义 。 但 是 
要 知道 ， 默 认 情 况 下 ， 第 一 种 类 型 的 统计 信息 只 会 为 那些 没有 对 象 统计 信息 的 对 象 进行 收集 。 但 是 ， 
可 以 通过 指定 hintdynamic sampling est _cdn(table alias) 强 制 收集 。 你 可 能 需要 在 有 统计 信息 但 是 统 
计 信 息 不 准确 时 做 这 件 事 。 这 个 hint 会 在 如 果 不 强制 就 不 会 收集 时 强制 进行 收集 。 

动态 采样 收集 的 第 二 种 类 型 的 统计 信息 包含 以 下 几 项 : 

口 谓词 的 选择 率 

口 连接 的 基数 ( 仅 从 12.1 版 本 开始 ) 

口 聚合 的 基数 ( 仅 从 12.1 版 本 开始 ) 
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因为 这 些 统计 信息 超出 了 通过 对 象 统计 信息 能 提供 的 信息 ( 尽管 在 某 些 情形 中 谓词 的 选择 率 可 以 
通过 扩展 统计 信息 获得 )， 它 们 意图 增加 对 和 象 统计 信息 能 够 提供 的 信息 。 有 了 它们 ， 查 询 优化 器 可 能 
能 够 执行 更 好 的 估算 。 

下 面 的 例子 ( 11.2.0.3 版 本 中 运行 的 dynamic_sampling levels.sql 肢 本 生成 的 摘录 ) 表明 在 哪 种 情 
况 下 1 和 4 之 间 的 值 会 引导 动态 采样 发 生 。 用 于 测试 的 表 通 过 下 面 的 SQL 语 句 创 建 。 最 初 ， 它 们 没有 对 
象 统计 信息 。 注 意 ，t_noidx 表 和 t_idx 表 唯一 的 不 同 是 后 者 有 一 个 主键 ( 因此 也 就 有 一 个 索引 ): 

CREATE TABLE t noidx (id, ni, n2, pad) AS 

SELECT rownum, 

TOWnum， 
cast(round(dbms random.value(1,100)) AS VARCHAR2(100))， 
cast(dbms random.string('p',1000) AS VARCHAR2(1000)) 


FROM dual 
CONNECT BY level “= 1000 


CREATE TABLE t idx (id CONSTRAINT t idx pk PRIMARY KEY, n1i, n2, pad) AS 
SELECT:S 
FROM t noidx 


下 面 是 首次 执行 的 测试 查询 。 它们 之 间 的 唯一 区 别 是 , 第 一 个 引用 的 是 t_noidx 表 , 第 二 个 引用 的 
是 t idx 表 : # 


SELECT 兰 
FROM t noidx t1, t noidx t2 
WHERE t1.id = t2.id AND tl.id < 19 


SELECT 2 
EROM t jidx t1; t idx +2 


WHERE t1.id = t2.id AND t1.id «< 19 


如 果 将 级 别 设置 为 1， 则 只 会 在 第 一 查询 中 执行 动态 采样 ， 因 为 第 二 个 查询 引用 的 表 上 有 索引 。 
下 面 是 为 我 的 测试 库 上 的 t_noidx 表 收集 统计 信息 时 执行 的 递归 查询 。 为 了 更 容易 阅读 ， 一 些 hint 被 去 
掉 了 ,并 且 用 字面 值 替 换 了 绑 定 变量 。 注 意 在 执行 这 个 测试 查询 之 前 已 打开 SQL 跟 踪 。 接 下 来 我 要 做 
的 仅仅 是 观察 生成 的 跟踪 文件 以 找 出 执行 的 是 哪 一 个 递归 SQL 语句 : 
SELECT NVL(SUM(C1),0), 
NVL(SUM(C2),0), 
COUNT(DISTINCT C3), 
NVL(SUM(CASE WHEN C3 IS NULL THEN 1 ELSE 0 END),0) 
FROM ( 
SELECT 3 AS'CL, 
CASE WHEN "T1"."ID"<19 THEN 1 ELSE 0 END AS C2, 
“TT "Te WS 克 
FROM "CHRIS"."T NOIDX" SAMPLE BLOCK (20 , 1) SEED (1) "T1" 
) SAMPLESUB 


下 面 是 需要 重点 关注 的 内 容 。 

口 查询 优化 器 计算 总 的 行 数 ， 在 WHERE 子 句 (id < 19 ) 中 指定 范围 内 的 行 数 ， 以 及 唯一 值 的 数量 
和 id 列 空 值 的 数量 。 
口 必须 要 知晓 查询 中 使 用 的 值 。 如 果 使 用 了 绑 定 变量 ， 查 询 优 化 器 必须 能 够 窥探 绑 定 变量 以 便 
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执行 动态 采样 。 
口 SAMPLE 子 句 是 用 来 执行 采样 的 。 在 我 的 数据 库 中 t_noidx 表 占用 了 155 个 块 ， 所 以 采样 百分比 为 
20% ( 32/155 )。 


警告 根据 你 要 处 理 的 数据 ， 可 能 需要 级 别 6 或 7 来 确保 动态 采样 生成 有 代表 性 的 信息 。 毕 竞 ， 即 使 
是 级 别 7， 最 多 也 只 抽取 256 个 块 。 依 赖 于 数据 总 量 和 数据 分 布 情况 ， 抽 取 很 少数 量 的 数据 块 
可 能 不 足以 正确 地 代表 一 张 表 的 整体 内 容 。 


如 果 将 级 别 设置 为 2， 则 在 两 个 测试 查询 中 都 会 执行 动态 采样 ， 在 这 个 级 别 ， 当 对 象 统计 信息 缺 
失 时 总 是 会 使 用 动态 采样 。 用 来 为 两 张 表 收 集 统计 信息 的 递归 查询 和 之 前 展示 的 语句 是 相同 的 。 抽 取 
百分比 的 增加 是 因为 ， 在 这 个 级 别 上 ， 它 是 基于 64 个 块 而 不 是 32 个 。 此 外 ， 对 于 t_idx 表 ， 也 会 执行 
下 面 的 递归 查询 。 它 的 目的 是 通过 扫描 索引 代替 之 前 查询 中 扫描 的 表 。 这 么 做 是 因为 ,在 表 上 执行 快 
速 采样 可 能 会 漏 掉 在 WHERE 子 句 中 谓词 指定 范围 内 出 现 的 数据 。 而 如 果 这 些 数 据 存在 ， 在 索引 上 的 快 
速 扫描 一 定 会 定位 到 它们 : 


SELECT NVL(SUM(C1),0), 
NVL(SUM(C2) ,0), 
NVL(SUM(C3),0) 

FROM ( 

SELECT 4 AS C1s 
1 AS (2; 
1 AS' C3 
FROM "CHRIS"."T IDX” "T4" 
WHERE "T1"."ID"<19 
AND ROWNUM <= 2500 
) SAMPLESUB 


动态 采样 的 下 一 个 级 别 是 3。 从 这 个 级 别 开 始 ， 动 态 采 样 也 用 于 数据 字典 中 有 可 用 的 对 象 统计 信 
息 的 情况 。 在 执行 进一步 的 测试 之 前 ， 通 过 下 面 的 PL/SQL 代 码 块 收集 对 象 统计 信息 : 


BEGIN 
dbms_ stats.gather table stats(ownname => User, 
tabname = 't noidx", 
method opt => 'for all columns size 1'); 
dbms stats.gather table stats(ownname => User, 
tabname =》 ' 守 dx", 
method opt => "for all columns size 1 ， 
cascade => true); 
END; 


如 果 将 级 别 设置 为 3 或 更 高 ， 查 询 优 化 器 会 执行 动态 采样 ， 然 后 通过 测算 表 中 数据 样本 的 选择 率 
来 估算 谓词 的 选择 率 ， 而 不 是 使 用 来 自 数据 字典 的 统计 信息 以 及 可 能 是 硬 编码 的 值 。 下 面 的 两 个 查询 
验证 了 这 一 点 : 


SELECT * 
FROM t idx 
WHERE id = 19 
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SELEGT 粒 
FROM t idx 
WHERE round(id) = 19 


对 于 第 一 个 查询 ， 查 询 优 化 器 能 根据 列 统计 信息 和 直方 图 估算 id=19 这 个 谓词 的 选择 率 。 因 此 没 
有 必要 进行 动态 采样 。 相 反 ， 对 于 第 二 个 查询 ( 除非 round(id) 表 达 式 上 有 扩展 的 统计 信息 存在 ), 查 
询 优 化 器 无 法 推断 出 round(id)=19 这 个 谓词 的 选择 率 。 事 实 上 ， 列 统计 信息 和 直方 图 只 提供 关于 id 
列 自身 的 信息 ， 并 没有 关于 舍 人 值 的 。 下 面 的 查询 是 用 于 动态 采样 的 。 正 如 所 看 到 的 ， 它 与 之 前 讨 
论 的 那个 查询 有 着 相同 的 结构 。c2 和 c3 列 不 同 是 因为 导致 动态 采样 的 SQL 语句 中 的 NMHERE 子 句 不 同 了 。 
因为 一 个 表达 式 作 用 于 索引 的 列 (id ) 上 ， 与 t_ idx 表 一 样 ， 所 以 在 这 个 特殊 的 案例 中 在 索引 上 没有 
执行 采样 : 
SELECT NVL(SUM(C1) ,0)， 
NVL(SUM(C2),0)， 
COUNT(DISTINCT C3) 
FROM ( 
SELECT 1 AS C1, 
CASE WHEN ROUND("T IDX"."ID")=19 THEN 1 ELSE 0 END AS C2, 
ROUND("T_IDX"."ID") AS C3 


FROM "CHRIS"."T IDX" SAMPLE BLOCK (20 , 1) SEED (1) "T_IDX" 
) SAMPLESUB F 


如 果 将 级 别 设置 为 4 或 更 高 ， 当 WHERE 子 句 中 引用 同一 张 表 中 的 两 个 或 两 个 以 上 列 时 查询 优化 器 也 
会 执行 动态 采样 。 这 样 做 有 助 于 在 有 相关 列 的 情况 下 改进 估算 能 力 。 下 面 的 查询 提供 了 一 个 这 方面 的 
例子 。 如 果 你 回头 查看 创建 测试 表 使 用 的 SQL 语句 ， 你 会 注意 到 id 和 nl1 列 包含 同样 的 数据 : 

SELECT * 


FROM t idx 
WHERE id < 19 AND n1 < 19 


同样 在 本 例 中 ， 查 询 优 化 器 通过 与 之 前 的 例子 结构 相同 的 查询 执行 动态 采样 。 同 样 ， 主 要 的 区 别 
还 是 在 于 引起 动态 采样 的 SQL 语句 的 NHERE 子 句 : 
SELECT NVL(SUM(C1) ,0)， 
NVL(SUM(C2),0) 
FROM ( 
SELECT 1 AS C1, 
CASE WHEN XI xT9 AND "T_TDX"."Ni"<19 THEN 1 ELSE 0 END AS C2 


FROM "CHRIS"."T IDX" SAMPLE BLOCK (20 , 1) SEED (1) "T_IDX" 
) SAMPLESUB 


总 结 一 下 ， 你 可 以 发 现 级 别 1 和 级 别 2 通常 没有 太 大 的 帮助 。 事 实 上 ， 表 和 索引 都 应 该 拥有 最 新 的 
对 象 统计 信息 。 一 个 常见 的 例外 是 当 临 时 表 包 含 的 临时 数据 被 访问 的 时 候 ， 临 时 表 可 以 由 全 局 临时 表 
或 普通 表 实 现 。 实 际 上 ， 对 于 它们 来 讲 经 常 没有 对 象 统计 信息 可 供 访问 。 关 于 临时 表 的 例外 情况 是 ， 
在 12.1 版 本 中 ， 你 可 以 利用 会 话 级 别 统计 信息 。 不 管 怎样 ， 要 知道 一 个 会 话 可 以 共享 另 一 个 会 话 解析 
的 游标 ， 即 使 这 一 时 刻 它 被 使 用 了 ， 与 临时 表 关联 的 段 包 含 完 全 不 同 的 数据 集 。 级 别 3 以 及 更 高 的 级 
别 对 于 改进 “复杂 ”谓词 的 选择 率 估算 非常 有 用 。 因 此 ， 如 果 查 询 优化 器 因为 “复杂 的 ”谓词 无 法 做 
出 正确 的 估算 ， 请 将 optimizer_ dynamic_sampling 初 始 化 参数 设置 为 4 或 更 高 的 值 。 和 否则， 就 保持 默认 
值 吧 。 此 外 ,在 第 8 章 中 提 到 过 ， 从 11.1 版 本 开始 可 以 在 表达 式 和 列 组 上 收集 统计 信息 。 所 以 在 某 些 情 
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形 下 ， 应 该 能 够 避免 动态 采样 。 
5. optimizer index cost adj 
optimizer index_cost adj 初始 化 参数 用 于 改变 通过 索引 扫描 的 表 访 问 的 成 本 。 合 法 的 值 为 从 1 到 
10 000。 默 认 值 是 100。 大 于 100 的 值 会 使 索引 扫描 成 本 更 加 高 昂 并 因此 倾向 于 全 表 扫 描 。 小 于 100 的 值 
会 使 索引 扫描 的 成 本 降低 。 
要 理解 这 个 初始 化 参数 对 于 成 本 公式 的 影响 , 描述 查询 优化 器 如 何 计算 与 基于 索引 范围 扫描 的 表 
访问 有 关 的 成 本 会 很 有 帮助 。 


索引 范围 扫描 是 对 多 个 键 值 的 索引 查找 。 如 图 9-4 所 示 ， 执 行 的 操作 如 下 。 
(1) 访问 索引 的 根 块 。 
(2) 遍历 分 支 块 来 定位 包含 第 一 个 键 值 的 叶子 块 。 


(3) 对 于 每 一 个 满足 搜索 条 件 的 键 值 ， 执 行 以 下 操作 : 
a. 提取 引用 数据 块 的 rowid; 


b. 访问 由 rowid 引 用 的 数据 块 。 


图 9-4 


在 基于 索引 范围 扫描 的 表 访 问 期 间 执行 的 操作 


一 次 索引 范围 扫描 执行 的 物理 读数 量 等 于 定位 包含 第 一 个 键 值 的 叶子 块 所 访问 的 分 支 块 的 数量 

(也 就 是 blevel 统 计 信息 )， 加 上 扫描 的 叶子 块 数量 ( leaf blocks 统 计 信息 乘 以 操作 的 选择 率 )， 再 加 

上 通过 rowid 访 问 的 数据 块 数量 ( clustering factor 统计 信息 乘 以 操作 的 选择 率 )。 这 样 就 得 到 了 公式 

9-3， 此 外 ， 合 并 考虑 了 optimizer index_cost _ adj 初始 化 参数 应 用 的 修正 。 

公式 9-3 基于 索引 范围 扫描 的 表 访 问 的 IO 成 本 

in_cost~(blevel+(leaf _blocks+cluctering _ factor): selectivity): es 的 2 

注意 ”在 公式 9-3 中 ， 相 同 的 选择 率 被 同时 应 用 于 计算 索引 访问 的 成 本 〈 图 9-4 中 的 3a 操 作 ) 和 表 访 问 
的 成 本 〈3b 操 作 )。 在 现实 中 ， 查 询 优化 器 可 能 会 为 这 两 个 成 本 计算 使 用 两 个 不 同 的 选择 率 ， 

当 只 有 一 部 分 过 滤 条 件 是 通过 索引 访问 实施 的 时 候 ， 才 有 必要 这 样 做 。 例 如 ， 当 一 个 索引 由 

三 个 列 组 成 而 第 二 个 列 上 没有 限制 条 件 时 ， 就 会 出 现 这 种 情况 。 
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概括 起 来 ， 你 可 以 看 到 optimizer index_cost adj 初始 化 参数 对 索引 访问 的 MO 成 本 有 着 直接 的 影 
响 。 将 它 设置 为 一 个 比 默认 值 小 的 值 时 ， 所 有 的 成 本 成 比例 下 降 。 在 某 些 情况 下 这 可 能 是 个 问题 ， 因 
为 查询 优化 器 会 对 其 估算 的 结果 进行 伟人 操作 。 这 就 意味 着 , 即使 一 些 索引 的 对 象 统计 信息 是 不 同 的 ， 
但 是 从 查询 优化 器 的 角度 来 看 它们 可 能 都 拥有 一 样 的 成 本 。 如 果 几 个 成 本 数值 上 相等 ， 查 询 优化 器 则 
根据 索引 的 名 称 决定 使 用 哪 一 个 ! 它 直接 按 字母 顺序 选择 第 一 个 。 在 接 下 来 的 例子 中 将 演示 这 个 问题 。 
注意 当 optimizer index_cost adj 初始 化 参数 和 索引 名 称 发 生变 化 时 ，INDEX RANGE SCAN 操 作 使 用 的 索 
引 是 如 何 变化 的 。 下 面 是 对 optimizer index_cost_ adj.sql 脚 本 生成 输出 的 一 段 摘录 ; 

SQL> ALTER SESSION SET OPTIMIZER_INDEX_COST_AD] = 100; 


SQL> SELECT * FROM 七 WHERE val1 = 11 AND val2 = 11; 


| Id | Operation | Name | 


| 0 | SELECT STATEMENT | 
|* 1 | TABLE ACCESS BY INDEX ROWID| T | 
|* 2 | INDEX RANGE SCAN | TVAL2 I | 


1 - filter("VAL1"=11) 到 
2 - access("VAL2"=11) 


SOL> ALTER SESSION SET OPTIMIZER INDEX COST ADJ = 10; 


| 0 | SELECT STATEMENT | | 
|* 1 | TABLE ACCESS BY INDEX ROWID| T 
|* 2 | INDEX RANGE SCAN | T_VALL I| 


1 - filter("VAL2"=11) 
2 - access("VAL1"=11) 


SQL ALTER INDEX t val1 i RENAME TO t val3 i; 


SQL> SELECT * FROM t WHERE val1 = 11 AND val2 = 11; 


| Id | Operation | Name | 
0 | SELECT STATEMENT | | 
1 | TABLE ACCESS BY INDEX ROWID| T | 
2 | INDEX RANGE SCAN | TVAL2 I | 


1 - filter("VAL1"=11) 
2 - access("VAL2"=11) 


要 避免 这 种 不 稳定 性 ， 通 常 我 不 推荐 将 optimizer index_cost adj 初 始 化 参数 设置 为 较 低 的 值 。 
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同样 重要 的 是 ， 系 统统 计 信息 提供 与 全 表 范 围 扫 描 相 关 的 成 本 的 修正 。 这 就 是 说 ， 如 果 系 统统 计 信 息 
就 位 ， 默认 值 通常 会 表现 良好 。 还 要 注意 系统 统计 信息 没有 这 个 参数 所 拥有 的 缺点 ， 因 为 系统 统计 信 
息 是 增加 成 本 而 非 降 低 成 本 。 

optimizer_index_cost adj 初始 化 参数 是 动态 的 , 并 且 可 以 在 实例 和 会 话 级 别 修改 。 在 12.1 版 本 的 
多 租户 环境 下 ， 也 可 以 在 PDB 级 别 设置 它 。 


6. optimizer index caching 

optimizer index_caching 初 始 化 参数 用 于 指定 在 in-list 遂 代 操 作 和 髓 套 循环 连接 的 执行 期 间 预期 
在 缓冲 区 中 缓存 的 索引 块 总 量 ( 按 百 分 比 算 )。 应 该 注意 到 ， 这 个 初始 化 参数 的 值 仅 被 查询 优化 器 用 
来 调整 它 的 估算 值 。 换 句 话 说， 它 并 不 指定 每 个 索引 应 该 由 数据 库 引擎 缓存 多 少 。 合 法 的 值 范围 是 从 
0 到 100。 默 认 值 是 0。 比 0 大 的 值 降低 in-list 迭 代 操 作 和 妨 套 循环 连接 的 内 部 循环 执行 的 索引 扫描 的 成 本 。 
正 因 如 此 ，optimizer_index_caching 人 参数 被 用 来 增加 这 些 操作 的 使 用 率 。 

公式 9-4 展 示 了 将 修正 应 用 于 前 一 小 节 呈 现 的 索引 范围 扫描 成 本 公式 ( 公式 9-3 ) 后 的 结果 。 

公式 9-4 基于 索引 范围 扫描 的 表 访问 的 IO 成 本 

io_cost = [eee +/leaf piocks selectivity): [ | 十 

optimizer _index_ cost _ ac 


100 


这 个 初始 化 参数 拥有 与 上 一 节 中 描述 的 optimizer index_cost_ adj 初始 化 参数 类 似 的 缺点 。 虽 然 
如 此 , 它 的 影响 普遍 较 小 主要 因为 两 个 原因 。 首 先 ， 它 只 用 于 艇 套 循 环 和 in-list 和 迭代 操作 。 其 次 ， 它 对 
于 用 于 索引 范围 扫描 的 成 本 公式 ( 公式 9-4 ) 的 群集 因子 部 分 没有 影响 。 因 为 群集 因子 经 常 是 成 本 公式 
中 最 大 的 因子 ， 所 以 这 个 初始 化 参数 不 太 可 能 导致 错误 的 决定 。 总 之 ， 这 个 初始 化 参数 对 于 查询 优化 
器 的 影响 比 optimizer index_cost_adj 初 始 化 参数 要 小 。 也 就 是 说 ， 默 认 值 通常 工作 良好 。 

optimizer_index_caching 初 始 化 参数 是 动态 的 ， 并 且 可 以 在 实例 和 会 话 级 别 修改 。 在 12.1 版 本 的 
多 租户 环境 下 ， 也 可 以 在 PDB 级 别 设置 它 。 


clustering _ factor selectivity}: 


7. optimizer secure view merging 

optimizer secure_view merging 初 始 化 参数 可 以 用 来 控制 类 似 视图 合并 和 谓词 迁移 之 类 的 查询 转 
换 ( 详 见 第 6 章 )。 可 以 将 它 设置 为 FALSE 或 TRUE。 默 认 值 是 TRUE。 

口 FALSE 人 允许 查询 优化 器 无 需 检查 应 用 查询 变换 是 否 会 导致 安全 问题 就 这 样 做 。 

口 TRUE 允许 查询 优化 器 在 只 有 应 用 查询 变换 不 会 导致 安全 问题 时 才 这 样 做 。 


注意 因为 名 称 的 原因 ， 你 可 能 会 认为 optimizer secure view merging 初 始 化 参数 只 与 视图 合并 有 
关 。 但 是 ， 它 控制 着 所 有 可 能 导致 安全 问题 的 查询 变换 。 用 这 个 名 称 的 原因 很 简单 : 最 初 实 
现 它 时 ， 它 只 能 控制 视图 合并 。 


要 理解 这 个 初始 化 参数 的 影响 ， 我 们 来 看 一 个 例子 ， 该 例子 演示 了 为 何 从 安全 的 角度 来 看 视图 合 
并 可 能 是 危险 的 ( 完整 示例 参见 optimizer_secure view merging.sql 肢 本 )。 
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假定 你 有 一 张 很 简单 的 表 ， 该 表 拥 有 一 个 主键 和 另外 两 个 列 : 


CREATE TABLE t ( 
id NUMBER(10) PRIMARY KEY， 
Class NUMBER(10), 
pad VARCHAR2(10) 
) 
基于 安全 的 原因 ， 你 想 要 通过 下 面 的 视图 来 提供 对 这 张 表 的 访问 。 注 意 通过 函数 应 用 的 过 滤 条 件 
来 部 分 地 显示 这 张 表 的 内 容 。 这 个 函数 是 如 何 实现 的 以 及 它 到 底 做 什么 不 重要 : 
CREATE OR REPLACE VIEW v AS 
SELEGT 符 


FROM 蒜 
WHERE f(class) = 1 


举 个 例子 , 一 个 有 权 使 用 这 个 视图 的 用 户 创 建 了 下 面 的 PL/SQL 函数 。 如 你 所 见 ， 它 会 直接 通过 对 
dbms_output 包 的 调用 来 显示 输入 参数 的 值 : 
CREATE OR REPLACE FUNCTION spy (id IN NUMBER, pad IN VARCHAR2) RETURN NUMBER AS 
BEGIN 
dbms_output.put line('id="||id||' pad="||pad); 
RETURN 1; 
END; 


将 optimizer_secure_view merging 初 始 化 参数 设置 为 FALSE， 可 以 运行 两 个 测试 查询 。 两 个 查询 都 
只 会 返回 允许 用 户 查 看 的 那 部 分 值 。 然 而 ， 在 第 二 个 查询 中 ,由 于 视图 合并 ， 在 查询 中 添加 的 函数 的 
执行 要 早 于 对 函数 实施 的 安全 检查 。 因 此 ， 你 能 够 看 到 你 本 不 能 够 访问 的 数据 : 


SOL> SELECT id, pad 
2 FROM V 
3 WHERE id BETWEEN 1 AND 5; 


区 


1 DIrMLTDXxxq 
4 AszBGEUGEL 


SOL> SELECT id, pad 
2 FROM V 
3 WHERE id BETWEEN 1 AND 5 
4 AND spy(id, pad) = 1; 


1 DrMLTDXxxq 

4 AszBGEUGEL 
id=1 pad=DIMLTDXxxq 
id=2 pad=XOZnqYRJwI 
id=3 pad=nlGfOBTxNK 
id=4 pad=AszBOEUGEL 
id=5 pad=qTSRNFjRGb 


将 optimizer secure view merging 设 置 为 TRUE， 第 二 个 查询 返回 如 下 的 输出 结果 。 你 可 以 看 到 ， 
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函数 和 查询 显示 了 相同 的 数据 : 


SQL> SELECT id, pad 
2 FROM v 
3 WHERE id BETWEEN 1 AND 5 
4 AND spy(id，pad) = 1; 


1 DrMLTDXxxq 

4 AszBGEUGEL 
id=1 pad=DrMLTDXxxq 
id=4 pad=AszBGEUGEL 


注意 ， 如 果 视 图 的 所 有 者 和 查询 的 发 起 者 是 同一 个 用 户 ，optimizer secure view merging 初 始 化 
参数 就 会 被 忽略 ( 因为 ， 阻 止 一 个 用 户 查 看 他 已 经 可 以 直接 通过 查询 视图 所 引用 的 表 来 读 取 的 数据 ， 
这 是 毫 无 意义 的 )。 

一 个 类 似 的 例子 ,但 是 用 来 展示 谓词 迁移 应 用 于 虚拟 私有 数据 库 ( VPD ) 谓词 上 时 的 影响 ， 可 以 
在 optimizer secure view merging vpd.sql 脚 本 中 找到 。 

概括 起 来 ， 通 过 将 optimizer_secure_view_merging 初 始 化 参数 设置 为 TUE， 查询 优化 器 检查 查询 
变换 是 否 会 导致 安全 问题 。 如 果 会 导致 这 种 问题 ， 则 查询 变换 不 会 被 执行 ， 此 时 性 能 表现 可 能 不 是 最 
优 的 。 基 于 这 个 原因 ， 如 果 你 没有 将 视图 也 没有 将 VPD 用 作 安 全 用 途 , 我 建议 你 将 optimizer_secure_ 
view merging 初 始 化 参数 设置 为 FALSE。 

optimizer_secure_view merging 初 始 化 参数 是 动态 的 ， 并且 可 以 在 实例 级 别 修改 。 在 12.1 版 本 的 
多 租户 环境 下 , 也 可 以 在 PDB 级 别 进行 设置 .但 是 如 果 用 户 拥有 MERGE VIEW 对 象 权 限 或 者 MERGE ANY VIEW 
系统 权限 ， 则 不 受 这 个 初始 化 参数 施加 的 限制 条 件 影响 。 要 知道 ， 默 认 的 dba 角 色 提 供 MERGE ANY VIEW 
系统 权限 。 


9.3.2 ”PGA 管理 


为 了 执行 在 内 存 中 存储 数据 的 SQL 操作 ( 例如 ， 排 序 操作 和 散 列 联接 )， 会 使 用 工作 区 。 这 些 工 
作 区 在 每 个 服务 进程 的 私有 内 存 (PGA ) 中 进行 分 配 。 本 节 将 描述 配置 这 些 工 作 区 的 初始 化 参数 。 

通常 ,更 大 的 工作 区 会 提供 更 好 的 性 能 。 因 此 ， 你 应 该 将 系统 中 可 用 的 未 分 配 内 存 用 于 工作 区 的 
分 配 中 。 但 是 ,在 修改 它 的 时 候 要 小 心 。 工 作 区 的 大 小 也 会 对 查询 优化 器 的 估算 产生 影响 。 可 以 预见 
的 是 , 改变 不 仅 会 体现 在 性 能 方面 , 也 会 体现 在 执行 计划 上 。 换 句 话说 , 如 果 想 避免 意 想不到 的 情况 ， 
那么 所 有 的 修改 都 应 该 是 经 过 仔细 测试 的 。 

总 的 来 说 ， 本 节 不 会 为 所 描述 的 初始 化 参数 提供 “合理 的 ” 值 。 为 某 一 个 应 用 程序 找 出 合理 值 的 
唯一 办 法 ， 是 测试 并 测量 达到 合理 的 性 能 所 需要 的 PGA 的 大 小 。 事实 上 ， 内 存 总 量 只 对 性 能 有 影响 而 
对 一 个 操作 该 如 何 执行 没有 影响 。 


1. workarea size policy 
workarea_size_policy 初 始 化 参数 指定 如 何 调 整 工 作 区 大 小 的 工作 。 可 以 将 它 设 置 为 下 面 两 个 值 
中 的 一 个 s 
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口 auto: 单个 工作 区 的 大 小 调整 委托 给 内 存 管理 器 。 通 过 pga_aggregate_target 初 始 化 参数 ， 只 
有 整个 系统 的 PGA 总 量 被 指定 。 这 是 默认 值 。 
口 manual: 通过 hash area size、sort area size、sort area retained sizel 以 及 bitmap_merge_ 
area_size 初 始 化 参数 ， 可 以 完全 控制 工作 区 大 小 的 调整 。 
在 大 多 数 情形 中 ， 内 存 管 理 器 运行 良好 ， 所 以 极力 推荐 将 PGA 的 管理 委托 给 它 。 只 有 在 很 少 的 情 
况 下 手工 精心 调整 可 以 提供 比 自动 PGA 管 理 更 好 的 结果 。 
workarea_size_policy 初 始 化 参数 是 动态 的 ， 并 且 可 以 在 实例 和 会 话 级 别 修改 。 因 此 可 以 在 系统 
级 别 启用 自动 PGA 管 理 ， 然 后 对 于 特殊 要 求 ， 在 会 话 级 别 切换 为 手工 PGA 管 理 。 在 12.1 版 本 的 多 租户 
环境 下 ， 也 可 以 在 PDB 级 别 进行 设置 。 


2. pga_aggregate target 

如 果 启 用 了 自动 PGA 管 理 ，pga_aggregate _target 参 数 指定 〈 按 字 节 ) 分 配给 一 个 数据 库 实例 
的 PGA 总 量 。 支 持 的 值 的 范围 是 从 10 MB~4TB。 默 认 值 是 系统 全 局 区 ( SGA ) 大 小 的 20%。 对 于 如 
何 使 用 这 个 值 很 难 给 出 任何 具体 的 建议 。 但 是 ,在 所 有 的 系统 上 ， 每 个 并 发 的 会 话 至 少 需要 几 兆 字 
节 的 内 存 。 


注意 自 11.1 版 本 开始 ,memory _target 和 memory -max_target 初 始 化 参数 可 以 用 于 指定 一 个 数据 库 实例 
使 用 的 内 存 总 量 (也 就 是 SGA 大 小 加 上 合计 的 PGA 大 小 ), 设置 了 这 两 个 参数 之 后 ,数据库 引 
掌 会 自动 按 需 要 在 SGA 和 PGA 之 间 重 新 分 配 内 存 。 在 这 样 的 配置 中 ，pga_aggregate target 初 
始 化 参数 仅 用 来 设置 PGA 的 最 小 值 。 


要 说 明 内 存 管理 器 是 如 何 工 作 的 , 我 在 11.2.0.3 版 本 中 执行 了 一 个 需要 60 MB 左右 PGA 的 查询 并 逐 
渐 递 增 并 发 会 话 的 数量 ( 1~50 )。 对 于 每 一 次 迭代 ， 都 检查 由 数据 库 实例 分 配 的 最 大 PGA 总 量 ， 并 查 
看 由 执行 查询 的 会 话 分 配 的 平均 PGA 总 量 。pga_ aggregate target 初 始 化 参数 被 设置 为 ! GB。 这 就 意 
味 着 ,如 果 目 标 兑 现 ， 应 该 最 多 有 17 个 会 话 ( 1 GB/60 MB ) 能 够 获得 必要 的 PGA 从 而 在 内 存 中 执行 整 
个 语句 。 图 9-5 展 示 了 测试 的 结果 。 正 如 你 所 看 到 的 , 数据 库 实例 分 配 的 最 大 PGA 增 长 了 , 与 配置 的 一 
样 ,， 达 到 了 1 GB。 注意 ,在 第 19 个 并 发 会 话 之 前 ， 系 统 PGA 与 会 话 数 差不多 成 比例 增长 。 超 过 17 个 会 
话 时 ， 系 统 开始 减少 提供 给 每 个 会 话 的 PGA 总 量 。 

一 定 要 理解 pga_aggregate_target 初 始 化 参数 的 值 并 非 一 个 硬性 限制 ， 而 是 更 倾向 于 一 个 目标 值 。 
因此 ， 如 果 指 定 的 值 过 低 ， 则 数据 库 引擎 可 以 自由 分 配 比 指定 的 值 更 多 的 内 存 。 之 所 以 允许 这 样 做 是 
因为 如 果 无 法 为 操作 分 配 请 求 的 内 存 则 会 导致 其 失败 。 但 是 你 仍然 可 以 使 用 pga_aggregate_limit 初 始 
化 参数 (参见 下 一 节 ) 设置 一 个 硬性 限制 。 这 个 参数 从 12.1 版 本 开始 可 用 。 在 这 之 前 的 版 本 中 它 不 可 用 。 

为 了 展示 一 个 数据 库 实例 过 度 分 配 PGA 的 案例 ， 我 通过 将 pga_aggregate_target 初 始 化 参数 设置 
为 128 MB 重新 运行 之 前 的 测试 。 换 句 话 说， 我 指定 的 值 远 远 不 够 运行 50 个 每 个 都 需要 60 MB 内 存 的 并 

人 会话。 图 9-6 显 示 了 测试 的 结果 。 你 可 以 看 到 , 即便 是 单个 会 话 也 无 法 获取 足够 的 PGA 来 在 内 存 中 执 
行 查询 。 实 际 上 ,那个 会 话 只 获得 了 所 需要 内 存 的 一 半 。 随 着 并 发 会 话 数量 的 增加 ， 越 来 越 多 的 PGA 
被 分 配 。 到 第 50 个 会 话 的 时 候 ， 使 用 了 大 约 400 MB 的 PGA 一 一 是 配置 的 目标 值 的 三 倍 还 多 。 
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图 9-6 ”如 果 通 过 pga_aggregate_target 初 始 化 参数 设置 的 目标 值 ( 本 例 中 是 128 MB ) 
过 低 ， 则 内 存 管理 器 不 会 遵守 它 


要 了 解 一 个 系统 是 否 经 历 过 PGA 过 度 分 配 的 情况 ， 可 以 使 用 接 下 来 针对 v$pgastat 视 图 的 查询 。 
( 注意 ,查询 的 输出 显示 的 是 数据 库 实例 运行 完 图 9-6 所 示 的 测试 之 后 的 最 终 状 态 。 ) 如 果 像 显示 的 那样 ， 
maximum PGA allocated 的 值 远 远 高 于 aggregate PGA target parameter 的 值 ， 就 表示 pga_aggregate_ 
target 初 始 化 参数 的 值 不 合适 。 在 这 种 情况 下 , 重要 的 是 要 了 解 过 度 分 配 发 生 的 频率 。 出 于 这 个 目的 ， 
over allocation count 统 计 信 息 表明 数据 库 实例 从 上 一 次 启动 后 不 得 不 分 配 比 通过 pga_aggregate_ 
target 初 始 化 参数 指定 的 值 更 多 的 PGA 的 次 数 。 理 想 情 况 下 这 个 值 应 该 是 0: 


SQL> SELECT name, value, unit 
2 FROM v$pgastat 
3 WHERE name IN ('aggregate PGA target parameter', 
4 ‘maximum PGA allocated’, 
5 'over allocation count'); 
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NAME VALUE UNIT 


aggregate POA target parameter 134217728 bytes 
maximum PGA allocated 418658304 bytes 
over allocation count 94 


你 还 可 以 通过 v$pgastat 视 图 获得 关于 当前 分 配 的 PGA 总 量 , 以 及 它们 中 有 和 多少 是 用 于 自动 或 手工 
工作 区 的 信息 。 下 面 的 查询 说 明了 这 一 点 。 注 意 尽管 拥有 total 前 级 的 统计 数据 提供 了 当前 的 使 用 情 
况 ， 拥 有 maximum 前 级 的 统计 数据 会 提供 自 上 一 次 数据 库 实例 启动 以 来 的 最 高 使 用 情况 : 


SQL> SELECT name, value, unit 
2 FROM v$pgastat 
3 WHERE name LIKE '% PCA allocated' OR name LIKE“% workareas’; 


NAME VALUE UNIT 
total PGA allocated 999358464 bytes 
maximum PGA allocated 1015480320 bytes 
total POA used for auto workareas 372764672 bytes 
maximum PGA used for auto workareas 614833152 bytes 
total POA used for manual workareas 0 bytes 
maximum POA used for manual workareas 0 bytes 


还 要 注意 ， 在 这 个 输出 当中 ， 分 配 的 PGA 只 有 一 部 分 是 用 于 工作 区 。 很 明显 ， 还 有 其 他 的 东西 
存储 在 PGA 中 。 关 键 点 是 ， 每 个 请 求 一 些 内 存 来 执行 SQL 语句 或 PL/SQL 子 程序 的 进程 都 能 够 分 配 一 
部 分 通过 pga_aggregate_target 初 始 化 参数 配置 的 PGA。 即使 这 些 内 存在 不 用 于 工作 区 的 情况 下 也 可 
以 完成 分 配 。 因 为 内 存 管理 器 无 法 控制 这 些 附加 的 内 存 结 构 ( 又 称 为 无 法 调整 的 内 存 ) 的 大 小 ， 部 
分 PGA 也 不 在 内 存 管理 器 的 控制 下 。 因 此 ， 根 据 系 统 负载 ， 工 作 区 可 用 的 PGA 总 量 会 随时 间 而 变化 。 
在 任意 给 定 的 时 刻 可 以 通过 aggregate PGA auto target 统 计 信 息 查 看 可 用 的 内 存 总 量 。 接 下 来 的 例 
子 是 来 自 pga_auto_target.sql 脚 本 输出 的 一 段 摘录 ， 显 示 了 如 何 通 过 PL/SQL 调 用 定义 的 收集 操作 来 
分 配 500 MB 的 PGA， 进 而 减少 工作 区 可 用 的 内 存 总 量 : 

SQL> SELECT name, value, unit 


2 FROM v$pgastat 
3 WHERE name LIKE “aggregate PGA %'; 


NAME VALUE UNIT 


aggregate POA target parameter 1073741824 bytes 
aggregate POA auto target 910411776 bytes 


SOL> execute pga pkg.allocate(500000) 


SOL> SELECT name, value, unit 
2 FROM v$pgastat 
3 WHERE name LIKE “aggregate PGA %'; 


NAME VALUE UNIT 


aggregate POA target parameter 1073741824 bytes 
aggregate PGA auto target 375754752 bytes 
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SQL> execute dbms_ session.reset package; 


SOL> SELECT name, value, unit 
2 FROM v$pgastat 
3 WHERE name LIKE “aggregate PGA %'; 


NAME VALUE UNIT 


aggregate POA target parameter 1073741824 bytes 
aggregate POA auto target 910411776 bytes 


pga_aggregate_target 初 始 化 参数 是 动态 的 , 并 且 可 以 在 实例 级 别 修改 。 在 12.1 版 本 的 多 租户 环境 
下 ， 也 可 以 在 PDB 级 别 进行 设置 。 


3. pga_aggregate limit 

pga_aggregate_limit 初 始 化 参数 是 12.1 版 本 中 最 新 出 现 的 。 它 对 数据 库 实 例 可 以 使 用 的 PGA 总 量 
做 出 了 一 个 硬性 限制 。 这 个 参数 很 有 用 ， 因 为 就 像 上 一 节 描 述 的 那样 ， 通 过 pga_aggregate_target 初 
始 化 参数 设置 的 值 只 是 一 个 目标 值 ， 而 非 硬 性 限制 。 在 12.1 版 本 中 ， 如 有 必要 ， 可 以 同时 指定 一 个 硬 
性 限制 。 

pga_aggregate_limit 初 始 化 参数 的 默认 值 被 设置 为 以 下 值 中 较 大 的 那 一 个 : 

口 2 GB 

口 pga_aggregate_target 初 始 化 参数 的 值 的 两 倍 

口 3 MB 乘 以 processes 初 始 化 参数 的 值 

因此 ， 默 认 情况 下 会 强加 一 个 限制 。 要 避免 限制 就 必须 将 这 个 参数 设置 为 0。 将 这 个 参数 设 
置 为 一 个 比 默认 值 低 的 值 (除了 在 初始 化 文件 或 服务 器 参数 文件 中 ) 是 不 可 能 的 。 在 尝试 设置 比 
默认 值 低 的 限制 时 会 引发 以 下 错误 : 

SQL> ALTER SYSTEM SET pga aggregate limit = 10; 

ALTER SYSTEM SET pga aggregate limit = 10 


ERROR at line 1: 
ORA-02097: parameter cannot be modified because specified value is invalid 
ORA-00093: pga aggregate limit must be between 2048M and 1000000 


当 达 到 限制 时 ， 数 据 库 引擎 会 终止 调用 甚至 是 杀 掉 会 话 。 为 了 选择 要 处 理 的 会 话 ， 数 据 库 引擎 不 
考虑 最 大 的 PGA 利 用 率 。 相 反 ， 数据库 引擎 会 考虑 使 用 最 多 的 不 可 调整 内 存 总 量 的 会 话 。 当 调用 被 终 
止 时 ， 会 引发 以 下 错误 : 

ORA-04036: PGA memory used by the instance exceeds POA_ACGRECATE_LIMIT 


当 会 话 被 杀 掉 时 ,会 引发 一 个 典型 的 ORA-03113 错 误 : 


ORA-03113: end-of-file on communication channel 
Process ID: 5125 
Session ID: 17 Serial number: 39 


此 外 ， 会 将 类 似 下 面 这 样 的 对 应 的 信息 写 入 到 alert.1og 中 : 
PGA memory used by the instance exceeds PGA AGGREGATE LIMIT of 2048 MB 
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Immediate Kill Session#: 17, Serial#: 39 
Immediate Kill Session: sess: Ox77eb7478 05 pid: 5125 


pga_aggregate_limit 初 始 化 参数 是 动态 的 ， 并 且 只 能 在 实例 级 别 更 改 。 在 12.1 版 本 的 多 租户 环境 
下 ， 也 可 以 在 PDB 级 别 进行 设置 。 


4. sort area size 

如 果 启 用 了 手工 PGA 管 理 ，sort_area_size 初 始 化 参数 指定 ( 按 字 节 ) 用 于 合并 联接 、 排 序 以 及 至 
合 (包括 散 列 分 组 ) 的 工作 区 的 大 小 。 注 意 ， 这 是 一 个 工作 区 的 大 小 ， 而 一 个 单独 的 会 话 可 能 会 分 配 
多 个 工作 区 ( 详 见 第 14 章 )。 因 此 ， 用 于 整个 系统 的 PGA 总 量 取决 于 分 配 的 工作 区 的 数量 而 不 是 会 话 的 
数量 。 默 认 值 是 64 KB。 尽 管 几乎 不 可 能 给 出 关于 建议 值 的 一 般 性 建议 ,， 默认 值 确实 很 小 ， 而 通常 至 少 
需要 使 用 512 KB/1 MB。 值 得 注意 的 是 ， 工 作 区 并 非 总 是 完全 分 配 的 。 换 句 话 说， 通过 sort_area_size 
初始 化 参数 指定 的 值 只 是 一 个 限制 。 因 此 ， 指 定 一 个 比 实际 需要 大 的 值 不 一 定 会 有 问题 。 

sort area_size 初 始 化 参数 是 动态 的 , 并 且 可 以 在 实例 和 会 话 级 别 修改 。 在 12.1 版 本 的 多 租户 环境 
下 ,也 可 以 在 PDB 级 别 进行 设置 。 


5. sort area retained size 

在 上 一 节 中 ， 你 了 解 到 sort_area_size 初 始 化 参数 指定 用 于 排序 操作 的 工作 区 的 最 大 尺寸 。 尽管 
严格 来 说 ，sort_area_size 初 始 化 参数 只 是 指定 了 当 排 序 操作 发 生 时 使 用 的 内 存 总 量 。 当 获得 最 后 一 
行 并 将 其 包含 在 工作 区 中 存储 的 已 排序 结果 中 后 , 仍 需 将 内 存 仅 用 作 将 已 排序 结果 返回 给 父 操作 的 组 
冲 区 。sort_area_retained .size 初始 化 参数 指定 〈 按 字 节 ) 为 这 个 读 缓存 保留 的 内 存 总 量 。 这 个 初始 
化 参数 仅 用 于 启用 了 手工 PGA 管 理 时 。 尽 管 默认 值 是 从 sort area_size 初 始 化 参数 得 到 的 ， 在 
v$parameter 视 图 中 其 显示 为 0。 

要 设置 这 个 初始 化 参数 ,你 必须 清楚 ,如果 将 它 设置 为 一 个 比 sort_area_size 初 始 化 参数 低 的 值 ， 
并 且 结 果 集 无 法 纳入 到 保留 的 内 存 中 ， 当 排序 操作 完成 时 数据 就 会 涌 和 临时 段 中 。 即 使 排序 操作 本 身 
是 完全 在 内 存 中 执行 的 ， 也 可 能 发 生 这 种 情况 ! 因此 ， 为 了 更 好 的 性 能 而 使 用 默认 值 是 明智 的 。 只 有 
当 系 统 真 的 在 内 存 上 提 初 见 肘 时 ， 才 有 理由 设置 这 个 参数 。 

sort_area_retained_size 初 始 化 参数 是 动态 的 ， 并 且 可 以 在 实例 和 会 话 级 别 进行 修改 。 在 12.1 版 
本 的 多 租户 环境 下 ， 也 可 以 在 PDB 级 别 进行 设置 。 

6. hash area size 

如 果 启 用 了 手工 PGA 管 理 ，hash_area_size 初 始 化 参数 指定 ( 按 字 节 ) 用 于 散 列 联接 的 工作 区 的 
大 小 。 要 清楚 这 是 一 个 工作 区 的 大 小 ， 而 一 个 单独 的 会 话 可 能 会 分 配 多 个 工作 区 。 这 意味 着 用 于 整个 
系统 的 PGA 总 量 取决 于 分 配 的 工作 区 的 数量 而 非 会 话 的 数量 。 默 认 值 是 sort_area_size 初 始 化 参数 值 
的 两 倍 。 同 样 ， 给 出 具体 的 建议 值 非常 困难 。 不 管 怎样 ， 对 于 多 达 4 MB 的 值 ， 至 少 应 该 将 其 设置 为 
sort area_size 初 始 化 参数 值 的 四 到 五 倍 。 如 果 不 这 样 ， 查 询 优 化 器 可 能 会 对 散 列 联接 的 成 本 评估 过 
高 ， 并 因此 倾向 于 为 它们 使 用 合并 联接 。 同 样 ， 工 作 区 并 非 总 是 完全 分 配 的 。 换 句 话 说， 通过 
hash_area_size 初 始 化 参数 指定 的 值 只 是 一 个 限制 值 。 指 定 一 个 比 实际 需要 大 的 值 不 一 定 会 有 问题 。 

hash_area_size 初 始 化 参数 是 动态 的 , 并 且 可 以 在 实例 和 会 话 级 别 进行 修改 。 在 12.1 版 本 的 多 租户 
环境 下 ， 也 可 以 在 PDB 级 别 进行 设置 。 
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7.bitmap merge area size 

如 果 启 用 了 手工 PGA 管 理 ，bitmap_merge_area_size 初 始 化 参数 指定 ( 按 字 节 ) 用 于 合并 与 位 图 
索引 关联 的 位 图 的 工作 区 大 小 。 默 认 值 是 1 MB。 再 说 一 次 , 几乎 不 可 能 给 出 关于 建议 值 的 一 般 性 建议 。 
很 明显 ， 如 果 使 用 了 很 多 位 图 索引 ( 例如 ， 由 于 星 型 转换 的 原因 ， 参 见 第 14 章 )， 则 更 大 的 值 可 能 会 
改进 性 能 。 

bitmap_merge_area_size 初 始 化 参数 是 静态 参数 , 并 且 不 能 在 系统 或 会 话 级 别 进行 修改 。 因此 必须 
要 重启 数据 库 实例 才能 设置 它 。 在 12.1 版 本 的 多 租户 环境 下 ,不 可 以 在 PDB 级 别 进行 设置 。 


9.4 小 结 


本 章 主 要 讲述 如 何 通 过 设置 初始 化 参数 来 实现 查询 优化 器 的 合理 配置 。 因 此 ,不 仅 要 理解 初始 化 
参数 是 如 何 工 作 的 ， 还 要 理解 对 象 和 系统 统计 信息 是 如 何 影 响 查 询 优化 器 的 。 

即使 完成 了 最 佳 配 置 ， 查 询 优 化 器 也 可 能 出 现 无 法 找 出 高 效 执行 计划 的 情况 。 对 一 个 SQL 语句 的 
性 能 有 疑问 时 ， 首 先 需要 做 的 就 是 审查 执行 计划 。 第 10 章 将 讨论 如 何 获得 执行 计划 ， 以 及 更 重要 的 ， 
如 何 解释 它们 ， 另 外 也 会 介绍 一 些 识 别 低 效 执行 计划 的 规则 。 


执行 计划 


执行 计划 描述 数据 库 引 擎 执行 SQL 语句 时 实施 的 操作 。 每 当 你 不 得 不 去 分 析 一 个 与 SQL 语句 有 关 
的 性 能 问题 时 ， 或 者 对 查询 优化 器 创造 条 件 做 出 的 决定 有 疑问 时 ， 你 必须 了 解 执 行 计划 。 没 有 它 ,你 
就 像 一 个 拿 着 拐杖 的 盲人 走 在 撒哈拉 大 沙漠 的 中 央 ， 四 处 摸索 着 试图 找 出 一 条 出 路 。 当 分 析 或 质疑 一 
个 SQL 语句 的 性 能 时 ， 需 要 做 的 第 一 件 事 就 是 获取 它 的 执行 计划 ， 这 再 怎么 强调 都 不 为 过 。 

无 论 何 时 处 理 一 个 执行 计划 , 你 都 需要 实施 三 个 基本 操作 : 获取 它 , 解释 它 , 然后 评估 它 的 效率 。 
本 章 的 目标 是 详细 描述 应 该 如 何 执行 这 三 个 操作 。 


10.1 获取 执行 计划 


基本 上 ，Oracle Database 提 供 五 种 方法 来 获取 与 某 个 SQL 语句 关联 的 执行 计划 。 

口 执行 EXPLAIN PLAN 语句 然后 查询 其 输出 所 写 和 的 表 。 

口 查询 动态 性 能 视图 来 显示 缓存 在 库 缓存 中 的 执行 计划 。 

口 使 用 实时 监控 ( Real-time Monitoring ) 来 获取 关于 正在 执行 或 刚刚 执行 完毕 的 SQL 语句 的 信息 。 

口 查询 自动 工作 负载 存储 库 ( AWR ) 或 statspack 表 ， 显 示 存 储 在 存储 库 中 的 执行 计划 。 

口 激活 跟踪 功能 提供 执行 计划 。 

尽管 还 有 其 他 获取 执行 计划 的 方法 〈 例 如 ， 在 第 11 章 中 会 讲 到 ， 通 过 与 SQL 探查 和 SQL 计划 基线 
相关 的 特性 )， 但 是 那些 方法 无 法 直接 用 来 获取 一 个 与 给 定 SQL 语句 关联 的 执行 计划 。 因 此 ， 本 章 不 
会 介绍 这 些 内 容 。 因 为 所 有 显示 执行 计划 的 工具 都 是 利用 刚才 所 列 的 五 种 方法 之 一 ， 接 下 来 的 内 容 只 
会 讲述 基础 知识 而 不 会 关注 某 个 具体 的 工具 , 例如 Oracle Enterprise Manager、PL/SQL Developer 或 Toad 
等 。 不 讨论 这 些 工 具 的 原因 还 有 ， 多 半 情 况 下 ， 它 们 无 法 提供 进行 一 个 完全 分 析 所 需 的 全 部 信息 。 注 
意 ， 实 时 监控 已 在 第 4 章 中 提 到 过 。 


10.1.1 ”EXPLAIN PLAN 语句 


EXPLAIN PLAN 的 目标 是 接受 一 个 SQL 语句 作为 输入 ， 然 后 提供 它 的 执行 计划 和 相关 信息 ， 并 在 计 
划 表 中 作为 输出 显示 。 换 名 话说， 通过 这 个 语句 可 以 询问 查询 优化 器 ， 什 么 样 的 执行 计划 将 用 于 给 定 
SQL 语句 的 执行 。 

图 10-1 展 示 了 EXPLAIN PLAN 语句 的 语法 。 可 用 的 参数 如 下 。 

口 statement 指 定 应 该 为 哪 一 条 SQL 语句 提供 执行 计划 。 支 持 的 SQL 语句 如 下 : SELECT、INSERT、 
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UPDATE 、MERGE 、DELETE 、CREATE TABLE、CREATE INDEX 以 及 ALTER INDEX。 

口 id 指定 一 个 名 称 ， 用 于 区 分 存储 在 计划 表 中 的 多 个 执行 计划 。 支 持 30 个 字符 以 内 的 任何 字符 
串 。 这 个 参数 是 可 选 的 ， 默认 值 是 NULL。 

口 table 指 定 将 关于 执行 计划 的 信息 插入 到 的 计划 表 的 名 称 。 这 个 参数 是 可 选 的 ， 默 认 值 是 
plan_table。 一 旦 有 和 需要， 也 可 以 使 用 通常 的 语法 指定 一 个 模式 名 以 及 数据 库 链 接 名 : 
schema.table@dblink,。 


SET STATEMENT ID= || id INTO table 


EXPLAIN PLAN FOR [ef statement) > 


图 10-1 ”EXPLAIN PLAN 语句 的 语法 


一 定 要 认识 到 EXPLAIN PLAN 语句 是 一 个 DML 语 句 ， 而 非 一 个 DDL 语 句 。 这 意味 着 它 不 会 为 当前 的 
事务 执行 一 个 隐 式 提交 。 它 只 是 简单 地 将 数据 插入 到 计划 表 中 。 

要 执行 EXPLAIN PLAN 语句 ， 需 要 将 执行 SQL 语句 的 权限 作为 一 个 参数 传递 进去 。 注 意 当 获取 视图 
的 执行 计划 时 ， 同 样 需要 所 有 底层 表 和 视图 的 权限 。 因 为 这 有 点 违反 直觉 ， 看 一 下 下 面 的 例子 。 注 意 
为 何 用 户 能 够 执行 一 个 引用 user_objects 视 图 的 查询 却 不 能 为 相同 的 查询 语句 执行 EXPLAIN PLAN 语句 : 

SQL> SELECT count(*)FROM user objects; 


COUNT(*) 


SQL> EXPLAIN PLAN FOR SELECT count(*)FROM useriobjects; 
EXPLAIN PLAN FOR SELECT count(*)FROM user objects 
米 


ERROR at line 1: 

ORA-01039: insufficient privileges on underlying objects of the view 

就 像 错 误 信 息 中 指出 的 ， 用 户 缺 少 一 个 或 几 个 被 user_objects 视 图 引用 的 数据 字典 表 的 SELECT 
权限 。 


1. 计划 表 

计划 表 是 EXPLAIN PLAN 语句 输出 内 容 写 入 的 地 方 。 如 计划 表 不 存在 ， 则 会 抛 出 一 个 错误 。 默 认 的 
计划 表 归 SYS 所 有 , 一 个 名 为 plan_table 的 公共 同义词 将 这 张 表 暴 露 给 所 有 的 用 户 。 一 旦 需要 一 张 私有 
的 计划 表 , 通过 utlxplan.sql 脚 本 手工 创建 是 一 个 不 错 的 实践 ， 脚本 可 以 在 $0RACLE_HOME/rdbms/admin 
目录 下 找到 。 如 果 计 划 表 是 手工 创建 的 , 一 旦 执行 了 数据 库 升级 , 不 要 忘记 将 计划 表 删 掉 并 重新 创建 。 
实际 上 ， 这 往往 会 发 生 在 新 版 本 添加 了 新 属性 的 时 候 。 

有 趣 的 是 ， 默 认 的 计划 表 是 一 张 会 将 数据 存储 直到 会 话 结束 的 全 局 临时 表 "。 通 过 这 种 方式 ， 几 
个 并 发 的 用 户 可 以 同时 使 用 它 而 不 互相 干扰 。 

要 将 计划 表 与 EXPLAIN PLAN 语句 一 起 使 用 ， 至 少 需要 INSERT 和 SELECT 权限 。 尽 管 可 以 不 使 用 DELETE 


人 换 句 话说 ， 它 是 一 张 使 用 on commit preserve rows 选 项 创建 的 全 局 临时 表 。 
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权限 执行 基本 的 操作 ,但 最 好 还 是 授予 该 权限 。 

在 这 里 我 不 会 完整 地 描述 计划 表 ， 原 因 很 简单 : 你 通常 不 会 直接 查询 它 。 关 于 这 张 表 的 列 的 详 
细 描 述 ， 请 参考 Performance Tuning Guide( 11.2 及 之 前 的 版 本 ), 或 $OL Tuning Guide ( 从 12.1 版 本 
开始 ), 


2. 查询 计划 表 

很 显然 可 以 直接 通过 针对 计划 表 发 起 查询 来 获取 执行 计划 。 但 是 ,使 用 dbms_xplan 包 的 display 
函数 会 简单 得 多 , 如 接 下 来 的 例子 所 示 。 可 以 看 到 , 它 的 使 用 非常 简单 。 实际 上 , 为 了 显示 EXPLAIN PLAN 
语句 生成 的 执行 计划 ， 调 用 这 个 函数 就 足够 了 。 注 意 这 个 函数 返回 的 值 ( 即 一 个 结果 集 ) 是 如 何 通过 
table 函 数 转换 的 : 


SQL> EXPLAIN PLAN FOR SELECT * FROM emp WHERE deptno = 10 ORDER BY ename; 
SQL> SELECT * FROM table(dbms xplan.display); 


PLAN_TABLE_OUTPUT 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | 了 | ‘41] 3 (34)| 00:00:01 | 
| 1 | SORT ORDER BY | | :| 3 (34)| 00:00:01 | 
|* 2| TABLE ACCESS FULL| EMP | 了 | 44 | 2 (0) | 00:00:01 | 


2 - filter("DEPTNO"=10) 


display 晴 数 不 仅 仅 限于 不 带 参 数 的 用 法 。 基 于 这 个 原因 ， 本 章 稍 后 会 介绍 dbms_xplan 包 ,探索 所 
有 的 可 能 性 ， 包 括 对 产生 的 输出 的 描述 。 


3. 绑 定 变 量 陷阱 

我 遇 到 过 的 使 用 EXPLAIN PLAN 语句 最 常见 的 错误 是 ， 指 定 了 一 个 有 别 于 要 分 析 的 语句 的 SQL 语句 。 
当然 , 那 会 导致 错误 的 执行 计划 。 因为 格式 本 身 对 执行 计划 没有 影响 , 差别 通常 由 替换 绑 定 变量 引起 。 
来 检查 一 下 接 下 来 的 PL/SQL 存 储 过 程 中 查询 语句 使 用 的 执行 计划 : 

CREATE OR REPLACE PROCEDURE p (p_value IN NUMBER)IS 


BEGIN 
FOR i IN (SELECT * FROM emp WHERE empno = p_value) 
LOOP 
NULL; -- do something 
END LOOP; 
END; 


常用 的 技巧 是 使 用 字面 值 替 换 PL/SQL 变 量 来 复制 /粘贴 查询 语句 。 执 行 类 似 这 样 的 SQL 语 人 句 : 


EXPLAIN PLAN FOR SELECT * FROM emp WHERE empno = 7788 
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问题 是 通过 使 用 字面 值 蔡 换 绑 定 变量 ， 你 向 查询 优化 器 提交 了 一 条 不 一 样 的 SQL 语句 。 这 种 改变 
可 能 会 对 查询 优化 器 做 出 的 决定 产生 影响 。 改 变 是 因为 SQL 概要 、 存 储 纲要 、SQL 计 划 基 线 ( 详 见 第 
11 章 ) 的 存在 , 或 者 查询 优化 器 用 来 估算 在 WHERE 子 句 中 使 用 的 谓词 选择 率 的 方法 (字面 值 和 绑 定 变量 
不 是 按照 相同 的 方式 处 理 的 )。 

正确 的 途径 是 使 用 相同 的 SQL 语句 。 这 是 可 行 的 ， 因 为 绑 定 变 量 可 以 在 EXPLAIN PLAN 语句 中 使 用 。 
例如 ， 你 应 该 执行 类 似 的 SQL 语句 (注意 ，p_value PL/SQL 变 量 被 :B1 绑 定 变 量 替 换 了 ， 因 为 PL/SQL 
引擎 也 会 这 么 做 ): 

EXPLAIN PLAN FOR SELECT * FROM emp WHERE empno = :B1 


尽管 如 此 ， 在 EXPLAIN PLAN 语句 中 使 用 绑 定 变 量 有 两 个 问题 。 第 一 个 问题 是 ， 默 认 情 况 下 ， 绑 定 
变量 会 被 以 VARCHAR2 类 型 声明 。 结 果 ， 数 据 库 引擎 可 能 会 自动 添加 一 个 隐 式 转换 ， 而 那样 做 会 改变 执 
行 计划 。 这 点 可 以 通过 在 dbms xplan 包 中 的 display 函 数 生成 的 输出 的 末尾 显示 的 关于 谓词 的 信息 来 检 
查 。 在 下 面 的 输出 例子 中 ，to_number 函 数 被 用 于 这 个 目的 : 


SQL> SELECT * FROM table(dbms xplan.display); 


PLAN TABLE OUTPUT 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | | 38 | 1 (0)| 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| EMP | t | 38 | 1 (0)| 00:00:01 | 
|* 2 | INDEX UNIOUE SCAN | EMP_PK | 1 | | 0 (0)| 00:00:01 | 


2 - access("EMPNO"=TO_ NUMBER(:B1)) 
通常 ， 检 查 是 否 正 确 处 理 了 数据 类 型 是 很 好 的 做 法 ， 比 如 ， 通 过 为 原始 SQL 语 句 中 所 有 不 是 
VARCHAR2 类 型 的 绑 定 变 量 使 用 显 式 转换 。 
第 二 个 问题 是 在 EXPLAIN PLAN 语句 中 使 用 绑 定 变 量 时 不 会 使 用 绑 定 变量 扫 视 技术 。 因 为 这 个 问题 
没有 解决 方案 ， 所 以 不 能 保证 通过 EXPLAIN PLAN 语句 生成 的 执行 计划 就 是 运行 时 会 选择 的 执行 计划 。 
换 名 话说， 一 旦 涉及 绑 定 变量 ， 通 过 EXPLAIN PLAN 语句 生成 的 输出 是 靠不住 的 。 


10.1.2 动态 性 能 视图 


以 下 四 个 动态 性 能 视图 会 显示 关于 出 现在 库 缓存 中 的 游标 信息 。 

口 v$sql_plan 提 供与 计划 表 基 本 上 相同 的 信息 。 换 句 话 说, 它 提供 执行 计划 和 由 查询 优化 器 提供 
的 其 他 相关 信息 。 几 个 用 于 标识 与 库 缓存 中 的 执行 计划 关联 的 游标 的 列 ， 是 这 个 视图 与 计划 
表 之 间 唯 一 显著 的 差别 。 

口 v$sql plan_statistics 为 v$sql_plan 视 图 中 的 每 一 个 操作 提供 执行 统计 , 例如 消耗 的 时 间 和 产 
生 的 行 数 。 本 质 上 讲 , 它 提供 执行 计划 的 运行 时 行为 。 这 是 非常 有 用 的 信息 ， 因 为 v$sql_plan 


10.1 获取 执行 计划 271 


视图 只 显示 查询 优化 器 在 解析 阶段 做 出 的 估算 和 决定 。 因 为 执行 统计 信息 的 采集 可 能 会 引发 
不 可 忽略 的 负载 〈 依赖 于 执行 计划 和 数据 库 服务 器 运行 的 操作 系统 ， 负 载 也 可 能 是 微不足道 
的 ), 默认 情况 下 不 会 采集 它们 。 要 激活 采集 , 必须 将 statistics_level 初 始 化 参数 设置 为 all， 
或 者 必须 将 gather_plan_statistics 这 个 hint 指 定 在 SQL 语句 中 。 要 知道 ,因为 可 能 出 现 的 负载 ， 
我 不 推荐 在 系统 级 别 修改 statistics level 初始 化 参数 的 默认 值 。 

口 v$sql_workarea 提 供 关 于 执行 游标 所 需 的 内 存 工作 区 的 信息 。 它 给 出 运行 时 内 存 以 及 估算 的 高 
效 执行 操作 需要 的 内 存 总 量 信息 。 

口 v$sql plan statistics all 将 v$sql plan 、v$sql _ plan statistics 以 及 v$sql workarea 视 图 提 
供 的 信息 通过 一 个 单独 的 视图 展现 出 来 。 通 过 它 ， 可 以 避免 手工 连接 多 个 视图 。 

库 缓 存 中 的 游标 ( 因此 会 在 这 些 动态 性 能 视图 中 显示 ) 通过 两 个 列 来 标识 : address 和 
child_number。 通 过 address 列 ， 可 以 标识 父 游标 。 通 过 两 个 列 一 起 ， 可 以 标识 子 游标 。 更 常见 的 做 法 
是 用 sql id 列 替 代 address 列 来 标识 游标 。 使 用 sql _id 列 的 好 处 是 它 的 值 只 依赖 于 SQL 语句 本 身 。 换 名 
话说 ， 对 于 一 个 给 定 的 SQL 语句 ，sql_id 永 远 不 变 〈 事 实 上 ，sql_id 是 散 列 函数 应 用 于 SQL 语句 文本 
的 结果 ) 而 另 一 方面 ，address 列 是 一 个 指向 内 存 中 SQL 语句 的 句柄 的 指针 ， 并 会 随 着 时 间 而 改变 。 

要 标识 一 个 游标 ， 基 本 上 来 说 你 会 面临 两 种 搜寻 方法 ， 要 么 知道 执行 SQL 语句 的 会 话 ， 要 么 知道 
SQL 语句 的 文本 。 在 两 种 情况 下 ， 一 旦 标识 出 子 游标 ， 就 可 以 显示 它 的 相关 信息 了 。 


1. 标识 子 游标 

你 必须 面 对 的 第 一 种 常见 的 情况 是 ， 试 图 获取 关于 与 当前 连接 到 实例 的 会 话 有 关 的 SQL 语句 的 信 
息 。 在 这 种 情况 下 ， 可 以 在 v$session 视 图 上 执行 查找 。 当 前 执行 的 SQL 语句 是 通过 sql id (或 
sql_address ) 和 sql_child_number 列 来 标识 的 。 最 近 执 行 过 的 SQL 语句 是 通过 prev_ sql id (或 
prev_sql_addr ) 和 prev_child_number 列 来 标识 的 。 为 了 演示 这 种 方法 的 使 用 ， 我 们 假设 有 一 个 名 叫 
Curtis 的 用 户 给 你 打 电 话 ， 抱 怨 说 他 正在 苗 等 几 分 钟 以 前 通过 一 个 应 用 程序 提交 的 一 个 请 求 。 对 于 这 
个 问题 ， 直接 查询 v$session 视 图 很 有 效 ， 如 下 例 所 示 。 通 过 查询 的 输出 ,你 知道 当前 他 正 运行 着 一 个 
SQL 语句 ( 否则 ，status 列 不 会 是 ACTIVE )， 并 知道 与 这 个 会 话 关联 的 游标 是 哪个 : 


SQL> SELECT status, sql id, sql child _ number 
2 FROM v$session 
3 WHERE username = 'CURTIS'; 


STATUS SQL ID SQL_CHILD_NUMBER 


ACTIVE 1scu79x31qavt 1 

第 二 种 常见 的 情况 是 ， 你 知道 你 想 要 查找 更 多 信息 的 那个 SQL 语句 的 文本 。 在 这 种 情况 下 ， 可 以 
在 v$sql 视 图 上 执行 查找 。 与 游标 有 关联 的 文本 可 以 在 sql_text 和 sql_fulltext 列 中 找到 。 这 两 个 列 的 
区 别 是 第 一 个 列 只 通过 一 个 VARCHAR2 ( 1000) 的 值 显 示 部 分 的 文本 ， 而 第 二 个 列 通过 CLOB 类 型 的 值 显示 
全 部 文本 。 举 例 来 说 ， 如 果 你 知道 所 要 查找 的 SQL 语句 包含 一 段 online discount 的 文本 ， 就 可 以 使 用 下 
面 的 查询 来 找 出 游标 的 标识 符 ; 

SQL> SELECT sql _ id，child_number，sql_text 


2 FROM v$sql 
3 WHERE sql fulltext LIKE '%online discount%" 
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4 AND sql text NOT LIKE '%v$sql%'; 


soL ID CHILD NUMBER SOL TEXT 


1hqjydsjbvmwq 0 SELECT SUM(AMOUNT SOLD)FROM SALES S, PROMOTIONS P 
WHERE S.PROMO ID = P.PROMO ID AND PROMO SUBCATECORY 
= “online discount” 


2. 查询 动态 性 能 视图 

要 获得 执行 计划 ， 可 直接 在 v$sql_plan 和 v$sql_plan statistics all 视 图 上 执行 查询 。 但 是 ， 
还 有 更 简单 更 好 的 方式 来 完成 这 件 事 : 使 用 dbms_xplan 包 的 display_cursor 函 数 。 如 下 例 所 示 ， 其 
用 法 与 之 前 讨论 的 调用 display 函 数 相 似 。 唯 一 的 区 别 是 将 标识 要 显示 的 子 游标 的 两 个 参数 传递 给 这 
个 函数 : 

SQL> SELECT * FROM table(dbms xplan.display cursor('1ihqjydsjbvmwq', 0)); 


PLAN_ TABLE_ OUTPUT 


SELECT SUM(AMOUNT SOLD)FROM SALES S, PROMOTIONS P WHERE S.PROMO ID = 
P.PROMO ID AND PROMO SUBCATEGORY = "online discount' 


Plan hash value: 265338492 


| Id | Operation Name | Rows | Bytes | Cost (%CPU)| Time 

| 0 | SELECT STATEMENT | | | 139 (100)| | 
| 1 | SORT AGGREGATE i 元 驶 | | 
|* 2 | HASH JOIN | 913K| 26M| 139 (33)| 00:00:01 | 
|* 3 | TABLE ACCESS FULL | PROMOTIONS | 23 | 483 | 4 (0)| 00:00:01 | 
| 4| PARTITION RANGE ALL | 918K| 8075K| 123 (27)| 00:00:01 | 
| 5| TABLE ACCESS FULL | SALES | 918K| 8075K| 123 (27)| 00:00:01 | 


2 - access("S"."PROMO ID"="P"."PROMO ID") 
3 - filter("PROMO er “online discount') 


display_cursor 郑 数 并 不 限于 使 用 两 个 参数 标识 一 个 子 游标 。 出 于 这 个 原因 ， 本 章 稍 后 会 讲 到 
dbms_xplan 包 ， 来 探索 所 有 的 可 能 性 ， 包 括 对 生成 的 输出 的 描述 


10.1.3 自动 工作 负载 存储 库 和 Statspack 


捕获 某 个 快照 时 ， 自 动工 作 负载 存储 库 ( AWR ) 和 Statspack 就 能 够 收集 执行 计划 。 为 了 获取 执行 
计划 ,会 针对 上 一 节 中 描述 的 动态 性 能 视图 执行 查询 。 一 旦 可 用 ， 则 执行 计划 可 能 会 通过 Oracle 企 业 
管理 器 或 其 他 的 工具 在 报告 中 显示 。 对 于 AWR 和 Statspack, 存储 库 表 中 存储 的 执行 计划 都 与 v$sql_plan 


10.1 获取 执行 计划 273 


视图 中 存储 的 执行 计划 有 着 非常 类 似 的 结构 。 出 于 这 个 原因 ， 上 一 节 中 描述 的 技巧 在 这 里 也 适用 。 
存储 在 AWR 中 的 执行 计划 可 以 通过 dba hist sql_plan 视 图 访问 ( 从 12.1 版 本 开始 ， 也 可 以 使 用 
cdb hist sql _ plan 视图 访问 )。 要 查询 它们 ，dbms xplan 包 提供 了 display_awr 国 数 。 与 这 个 包 提供 的 
其 他 函数 一 样 ， 它 的 使 用 简单 明了 。 下 面 的 查询 是 一 个 例子 ( 注意 用 于 标识 SQL 语句 而 传递 给 
display_awr 函 数 的 参数 是 该 语句 的 sql_id );: 
SQL> SELECT * FROM table(dbms xplan.display awr('1hqjydsjbvmwq')); 


PLAN_TABLE_OUTPUT 


SELECT SUM(AMOUNT SOLD)FROM SALES S, PROMOTIONS P WHERE S.PROMO ID = 
P.PROMO ID AND PROMO SUBCATEGORY = "online discount' 


Plan hash value: 265338492 


| Id | Operation Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | | 1439 (100)| | 
| 1 | SORT AGGREGATE |【 志 1 | 30 | 
| 2 | HASH JOIN | 913K| 26M| 139 (33)| 00:00:01 | 
| 31 TABLE ACCESS FULL PROMOTIONS | 23 | 483 | 4 (0)| 00:00:01 | 
| 4| PARTITION RANGE ALL | 918K| 8075K| 123 (27)| 00:00:01 | 
| 5| TABLE ACCESS FULL | SALES | 918K| 8075K| 123 (27)| 00:00:01 | 


display_awr 函 数 并 不 只 限于 使 用 一 个 参数 来 标识 SQL 语 句 。 出 于 这 个 原因 ， 本 章 稍 后 会 讲 到 
dbms_xplan 包 ， 探 索 所 有 的 可 能 性 ， 包 括 对 生成 的 输出 的 描述 。 

当 使 用 一 个 大 于 或 等 于 6 的 级 别 捕获 快照 时 ，Statspack 将 执行 计划 存储 在 stats$sql_plan 存 储 库 表 
中 。 尽管 在 dbms xplan 包 中 没有 提供 具体 的 函数 来 查询 存储 库 的 表 , 但 是 可 以 利用 display 函 数 来 显示 
其 中 包含 的 执行 计划 。 可 以 在 display_statspack.sql 脚 本 中 找到 具体 的 例子 。 

此 外 ， 对 于 AWR 和 Statspack 两 者 ，Oracle 数 据 库 都 提供 了 实用 的 脚本 ， 为 具体 的 SQL 语句 高 亮 显 
示 一 段 时 间 内 执行 计划 的 改变 和 资源 消耗 的 变化 。 它 们 的 名 称 分 别 是 awrsqrpt.sql 和 sprepsql.sql。 
可 以 在 目录 $ORACLE_HOME/rdbms/admin 下 找到 它们 。 下面 是 来 自 awrsqrpt.sql 脚 本 生成 的 输出 的 一 段 摘 
录 。 根 据 输 出 结果 ， 在 分 析 的 时 间 段 内 SQL 语 句 的 执行 计划 发 生 了 改变 。 平均 运行 时 间 从 第 一 个 的 大 
概 8.3 秒 ( 16 577/2/1000 ) 到 了 第 二 个 的 3.7 秒 ( 14 736/4/1000 ) 左右 : 


SOL ID: 1hqjydsjbvmwq DB/Inst: DBM11203/DBM11203 Snaps: 576-577 
-> 1st Capture and Last Capture Snap IDs 

refer to Snapshot IDs witin the snapshot range 
-> SELECT SUM(AMOUNT SOLD) FROM SALES S, PROMOTIONS P WHERE S.PROMO ID = ... 


Plan Hash Total Elapsed 1st Capture Last Capture 
# Value Time(ms) Executions Snap ID Snap ID 
1 2446651477 465577 2 577 577 


2 265338492 14,736 4 577 577 
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Plan 1(PHV: 2446651477) 


Stat Name Statement Per Execution % Snap 
Elapsed Time (ms) 16,577 8,288.6 50.2 
CPU Time (ms) 16,071 8,035.3 50.9 
Executions 2 N/A N/A 
Buffer Gets 163,606 81,803.0 90.1 
Disk Reads 161,900 80,950.0 96.0 
Parse Calls 六 LQ 了 | 
Rows 2 外 < 四 N/A 
Id Operation | Name Rows Bytes | Cost (%CPU)| Time | 
0 | SELECT STATEMENT | | 2798 (100)| | 
1 SORT AGGREGATE | 9 30 | | | 
2 NESTED LOOPS | 913K 26M| 2798 (27)| 00:00:12 | 
3 TABLE ACCESS FULL | PROMOTIONS 23 | 483 | 4 (0)| 00:00:01 
4 PARTITION RANGE ALL | 39950 351K| 121 (27)| 00:00:01 | 
5 TABLE ACCESS FULL | SALES 39950 351K| 121 (27)| 00:00:01 | 


Stat Name Statement Per Execution % Snap 

Elapsed Time (ms) 14,736 3,684.0 44.6 

CPU Time (ms) 14,565 3504 人 12 46.1 

Executions 4 N/A N/A 

Buffer Gets 6,755 1,688.8 .7 

Disk Reads 6,485 1,621.3 3.8 

Parse Calls 车 0.3 6.5 

Rows 4 1.0 N/A 

Id Operation | Name | Rows | Bytes | Cost (%CPU)| Time 

0 | SELECT STATEMENT | | | 139 (100)| | 
1 SORT AGGREGATE | | 1 | 30 | | 
2 HASH JOIN | | 913K| 26M| 139 (33)| 00:00:01 | 
3 TABLE ACCESS FULL | PROMOTIONS | 23 | 483 4 (0)| 00:00:01 | 
4 PARTITION RANGE ALL| | 918K| 8075K| 123 (27)| 00:00:01 | 
5 TABLE ACCESS FULL | SALES | 918K| 8o75K| 123 (27)| 00:00:01 | 


10.1.4 ”跟踪 工具 
有 几 个 提供 关于 执行 计划 的 信息 的 跟踪 工具 。 遗 憾 的 是 ， 除 了 SQL 跟 踪 ( 参见 第 3 章 )， 它 们 中 没 
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有 一 个 是 受 官方 支持 或 记录 在 案 的 。 但 它们 或 许 会 派 上 用 场 ， 所 以 我 简单 介绍 其 中 的 两 个 。 


1. 10053 事 件 

如 果 你 正 因为 查询 优化 器 做 出 的 决定 而 陷入 严重 的 困境 , 并且 想 知道 到 底 是 怎么 回 事 ， 查询 优化 
器 跟踪 可 能 会 有 所 帮助 。 但 我 提醒 你 ， 阅 读 跟 踪 文 件 并 不 是 一 件 轻 松 的 任务 。 幸 运 的 是 ， 你 不 用 经 常 
去 读 那 些 文件 ， 除 非 你 是 真 的 对 查询 优化 器 的 内 部 工作 机 制 感 兴趣 。 

如 果 想 在 某 时 为 一 个 SQL 语 句 生 成 跟踪 文件 并 希望 手动 执行 这 条 语句 ， 常 见 的 做 法 是 将 它 髓 
入 到 下 面 两 条 SQL 语句 中 间 , 从 而 启用 和 禁用 10053 事 件 。 注意 跟踪 文件 只 有 在 执行 硬 解 析 时 才 会 
生成 : 


ALTER SESSION SET events “10053 trace name context forever’' 


ALTER SESSION SET events “10053 trace name context off' 

如 果 无 法 手动 执行 SQL 语句 ， 从 11.1 版 本 开始 你 可 以 通知 查询 优化 器 对 一 个 通过 具体 的 sql_id 指 
定 的 SQL 语句 在 下 次 发 生硬 解析 时 生成 一 个 跟踪 文件 。 要 启用 或 禁用 这 种 行为 ， 可 以 使 用 类 似 下 面 这 
样 的 SQL 语句 ( 当然, 你 需要 更 改作 为 参数 传递 的 sql_id )。 这 种 方法 的 好 处 是 可 以 让 应 用 程序 发 出 对 
应 的 SQL 语句 。 这 样 会 给 你 一 个 与 在 真实 执行 环境 中 执行 的 真正 SQL 语句 一 样 的 跟 足 文件 。 注 意 这 种 
方法 也 可 以 在 会 话 级 别 使 用 。 直 接 将 ALTER_ SYSTEM 语句 用 ALTER SESSION 语句 替换 就 可 以 : 

ALTER SYSTEM SET events 'trace[rdbms.SQL Optimizer.*][sql:9s5u1ik3vshsw4]' 


ALTER SYSTEM SET events.'trace[rdbms.SQOL Optimizer.#][sql:9Ss5u1k3vshsw4] off 

如 果 你 想 分 析 与 库 缓 存 中 存储 的 一 个 游标 关联 的 SQL 语句 ， 从 11.2 版 本 开始 ， 可 以 利用 
dbms_ sqldiag 包 中 的 dump_trace 过 程 。 这 种 方法 既 不 需要 执行 SQL 语句 , 也 不 需要 知道 SQL 语句 被 解析 
的 真实 环境 , 也 无 需 知道 与 游标 关联 的 绑 定 变量 的 值 。 这 个 过 程 会 从 库 缓存 中 取得 它 需 要 的 所 有 信息 ， 
并 通知 查询 优化 器 重新 优化 SQL 语句 并 转 储 一 个 跟踪 文件 。 下 面 演示 一 下 如 何 调用 它 : 

dbms sqldiag.dump_trace 人 


p_sql id => "30g1nn8wdymh3 ， 
p_child number => 0， 
p_component => "Optimizer', 
bp file id =》 "test" 
); 


这 个 过 程 的 输入 参数 如 下 所 示 

口 p_sql id 指定 要 处 理 的 父 游 标 。 

口 p_child_number 指 定子 游标 号 ， 它 与 p_ sql_ id 一起， 就 可 以 标识 要 处 理 的 子 游标 。 这 个 参数 是 
可 选 的 ， 且 默认 值 为 0。 

口 p_component 指 定 该 过 程 是 否 转 储 0ptimizer 或 Compiler 跟 踪 。 简 单 来 说 ， 前 者 模拟 设置 10053 
事件 ,后 者 在 跟踪 文件 中 写 入 更 多 的 信息 ， 

口 p file id 为 tracefile identifier 初 始 化 参数 指定 一 个 值 . 这 个 参数 是 可 选 的 ,并 且 默 认 值 为 NULL。 

与 你 如 何 启 用 跟踪 无 关 ,， 查询 优化 器 会 生成 包含 大 量 关 于 它 执 行 的 工作 信息 的 跟踪 文件 。 在 文件 


行 计划 而 执行 的 估算 信息 。 描 述 这 个 事件 生成 的 跟踪 文件 的 内 容 超出 了 本 书 的 范围 。 如 有 必要 ， 请 参 
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考 下 面 的 资源 。 

口 Wolfgang Breitling 的 论文 : 4 Look under the Hood of CBO: The 10053 Event, 

口 Oracle Support 文 档 : CASE STUDY: Analyzing 10053 Trace Files ( 338137.1 ), 

口 Jonathan Lewis 的 著作 Cost-Based Oracle Fundamentals( Apress，2006 ) 的 第 14 章 。 

每 个 服务 进程 都 会 将 它 解析 的 SQL 语句 的 所 有 数据 写 入 到 自己 的 跟踪 文件 中 。 这 不 仅 意味 着 跟踪 
文件 可 以 包含 关于 多 个 SQL 语句 的 信息 ， 而 且 一 旦 在 多 个 会 话 中 打开 跟踪 文件 的 生成 ， 也 会 出 现 多 个 
跟踪 文件 。 关 于 跟踪 文件 的 名 称 和 位 置信 息 ， 参 考 3.1.1 节 的 “找到 跟踪 文件 ”部 分 。 


2. 10132 事 件 

可 以 使 用 10132 事 件 引发 一 个 跟踪 文件 的 生成 ， 其 中 包含 与 每 次 便 解 析 关 联 的 执行 计划 。 如 果 想 
为 特定 的 模块 或 应 用 程序 保留 所 有 执行 计划 的 历史 记录 ,这 会 很 有 帮助 。 下 面 的 例子 展示 了 在 跟踪 文 
件 中 为 每 个 SQL 语 句 存储 的 这 种 类 型 的 信息 ,主要 是 SQL 语 句 和 它 的 执行 计划 ( 包含 关于 谓词 的 信息 ) 
注意 这 段 输出 中 我 裁 掉 的 两 个 部 分 ， 是 提供 关于 执行 环境 信息 的 一 长 串 参 数 和 补丁 修复 : 


----- Current SQL Statement for this session (sql id=gbxvdrz7jvt80)----- 
SELECT count(n)FROM t WHERE n BETWEEN 6 AND 19 
===== Explain Plan Dump ----- 


-------------------------------------- +----------------------------------- 二 
| Id | Operation | Name | Rows | Bytes | Cost | Time 

-------------------------------------- +----------------------------------- 十 
| 0 | SELECT STATEMENT | | | | 入 | 
| 1 | SORT AGGREGATE | | zl 可 | | | 
|2 | TABLE ACCESS FULL | T | 14| 182 | 2 | 00:00:01 | 
-------------------------------------- +-----------------------------------+ 


2 - filter(("N">=6 AND "N"<=19)) 


Content of other xml column 


db version 2 T2063 
parse schema  : CHRIS 
dynamic sampling: 2 
plan_hash : 2966233522 
plan_hash 2 : 1071362934 


Outline Data: 
/*+ 
BEGIN OUTLINE DATA 
IGNORE OPTIM EMBEDDED HINTS 
OPTIMIZER FEATURES ENABLE('11.2.0.3') 
DB_VERSION('11.2.0.3') 
ALL ROWS 
OUTLINE LEAF(@"SEL$1") 
FULL(@"SEL$1" "T"@"SEL$1") 
END OUTLINE DATA 
$$ 


Optimizer state dump: 
Compilation Environment Dump 
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optimizer mode hinted = false 
optimizer features hinted = 0.0.0 
_px_numa_support enabled = true 
total processor group count = 1 


Bug Fix Control Environment 
fix 3834770 = 1 
fix 3746511 = enabled 
End of Optimizer State Dump 
初始 化 参数 和 补丁 修复 信息 的 列表 特别 长 。 出 于 这 个 原因 , 根据 你 使 用 的 版 本 , 即使 最 简单 的 SQL 
语句 也 会 有 大 概 10~30 KB 的 数据 写 入 到 跟踪 文件 中 。 这 样 一 个 跟踪 文件 的 生成 可 能 是 一 个 相当 大 的 开 
销 。 应 该 在 只 有 真正 需要 时 才 激 活 10132 事 件 。10132 事 件 可 以 通过 以 下 方式 启用 和 禁用 。 
口 为 当前 会 话 启 用 和 禁用 此 事件 。 


ALTER SESSION SET events '10132 trace name context foreveT”" 


ALTER SESSION SET events '10132 trace name context off'’ 
口 为 整个 数据 库 启 用 和 禁用 此 事件 。 警 告 : 这 样 设 置 不 会 立即 生效 ， 只 会 对 修改 后 创建 的 会 话 
起 作用 。 


ALTER SYSTEM SET events '10132 trace name context forevet 


ALTER SYSTEM SET events “10132 trace name context off' 
每 个 服务 进程 都 会 将 关于 它 解析 的 SQL 语句 的 所 有 数据 写 人 到 自己 的 跟踪 文件 中 。 这 不 仅 意 味 着 
跟踪 文件 可 以 包含 关于 多 个 SQL 语句 的 信息 ， 而 且 一 旦 在 多 个 会 话 中 打开 跟踪 文件 的 生成 ， 也 会 出 现 
多 个 跟踪 文件 。 关 于 跟踪 文件 的 名 称 和 位 置信 息 ， 参 考 3.1.1 节 的 “找到 跟踪 文件 ”部 分 。 


10.2 dbms xplan 包 


在 本 章 前 面 你 看 到 了 dbms_xplan 包 可 以 用 来 显示 存储 在 多 个 位 置 的 执行 计划 : 其 中 包括 计划 表 中 
的 ， 库 缓存 中 的 , AWR 中 的 以 及 Statspack 存 储 库 中 的 。 接 下 来 的 章节 将 会 描述 此 程序 包 中 可 用 的 此 类 
子 数 。 首 先 ， 我 们 来 看 一 下 它们 生成 的 输出 。 


10.2.1 输出 


本 节 的 目标 是 解释 由 dbms_xplan 包 中 的 某 些 函 数 返回 的 输出 中 包含 的 信息 。 为 此 ,我 使 用 了 一 个 
输出 样 例 ， 该 样 例 由 dbms_xplan_output.sql 脚 本 生成 ， 包 含 大 部 分 可 用 的 部 分 。 因 为 一 页 书 不 足以 显 
示 所 有 的 信息 , 所 以 不 是 每 个 部 分 的 所 有 信息 都 显示 出 来 了 。 我 只 展示 了 关键 信息 。 如 果 缺 少 了 什么 ， 
我 会 指出 来 。 还 要 注意 ， 对 于 本 节 提 供 的 大 部 分 信息 ， 案 例 和 进一步 的 解释 会 在 本 章 稍 后 或 第 四 部 分 
中 给 出 。 输 出 的 第 一 部 分 如 下 所 示 : 


SQL_ID dwnnunj9nuztb, child number 0 


SELECT t2.* FROM t1, t2 WHERE tl1.n = t2.n AND t1.id > :t1 id AND 
t2.id BETWEEN :t2 id min AND :t2 id max 
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这 部 分 给 出 关于 SQL 语 句 的 以 下 信息 。 

口 sql_id 可 以 锁定 父 游标 。 此 信息 只 有 当 输 出 是 由 display_cursor 和 display_awr 函 数 生成 时 才 可 
用 。 

口 childnumber 与 sq1_id 一 起 可 以 锁定 子 游标 。 此 信息 只 有 当 输 出 是 由 display_cursor 因 数 生成 的 
时 候 才 可 用 。 

口 SQL 语句 的 文本 只 有 当 输 出 是 由 display_cursor 和 display_awr 函 数 生成 时 才 可 用 。 

第 二 部 分 展示 的 是 执行 计划 的 散 列 值 ， 以 及 在 表格 中 显示 的 执行 计划 本 身 。 以 下 是 摘录 : 


Plan hash value: 2539808735 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | | | 15 (100)| | 
医 生 而 名 情 | | | | | | 
|* 2 | HASH JOIN | | 14 | 7756 | 15 (7)| 00:00:01 | 
1 渴 省 TABLE ACCESS BY INDEX ROWID| T2 | 14 | 7392 | 4 (0)| 00:00:01 | 
i INDEX RANGE SCAN | T2PK | 14| | 2 (0)| 00:00:01 | 
| TABLE ACCESS FULL | 肖 | 876 | 22776 | 23 (0)| 00:00:01 | 


在 这 个 表格 中 ， 为 每 个 操作 都 提供 了 估算 信息 和 执行 统计 。 表 格 的 列 数 直 接 取 决 于 可 用 信息 的 总 


量 。 举 例 来 说 ,关于 分 区 的 信息 ， 并 行 处 理 的 信息 或 执行 统计 只 有 在 可 以 访问 时 才 会 显示 。 出 于 这 个 
原因 ， 由 同一 个 函数 使 用 一 模 一 样 的 参数 而 生成 的 两 份 输出 也 可 能 会 不 一 样 。 在 本 例 中 ,你 看 到 的 列 
是 默认 可 用 的 。 表 10-1 总 结 了 你 可 能 会 看 见 的 所 有 列 。 


表 10-1 包含 执行 计划 的 表格 的 列 


列 描 述 
基本 信息 〈 总 是 可 用 ) 


Id 执行 计划 中 每 一 步 操作 ( 行 ) 的 标识 符 。 如 果 数 字 以 星 号 开头 ， 就 表示 此 行 的 
谓词 信息 稍 后 可 供 查看 

Operation 要 执行 的 操作 ， 也 被 称 作 行 源 操作 (row source operation ) 

Nane 执行 操作 所 针对 的 对 象 

查询 优化 器 估算 

Rows and E-Rows 估算 的 由 操作 返回 的 行 数 

Bytes and E-Bytes 估算 的 由 操作 返回 的 数据 总 量 

TempSpc 和 E-Temp 估算 的 操作 需要 的 临时 表 空 间 总 量 ( 按 字 节 ) 

Cost (XCPU) 估算 的 操作 成 本 。 以 插入 方式 给 出 的 CPU 成 本 的 百分比 。 注 意 这 个 值 是 在 整个 
执行 计划 中 累积 的 。 换 句 话说; 父 操作 的 成 本 包含 子 操作 的 成 本 

Time 和 E-Time 估算 的 执行 操作 所 需要 的 时 间 总 和 (HH:MM:SS ) 

分 区 

Pstart 要 访问 的 第 一 个 分 区 的 编号 。 如 果 这 个 编号 在 解析 阶段 不 可 知 ， 则 值 是 KEY 或 
INVALID。 当 第 一 个 分 区 会 在 执行 阶段 确定 的 时 候 使 用 KEY 

Pstop 要 访问 的 最 后 一 个 分 区 的 编号 。 如 果 这 个 编号 在 解析 阶段 不 可 知 ， 则 值 是 KEY 


或 INVALID。 当 最 后 一 个 分 区 会 在 执行 阶段 确定 的 时 候 使 用 kEY 


列 

并 行 和 分 布 式 处 理 
Inst 

To 

IN-OUT 

PO Distrib 
运行 时 统计 
Starts 


A-Rows 
A-Time 
IO 统计 ” 
Buffers 
Reads 
Writes 
内 存 使 用 率 统计 
OMem 
1Mem 
0/1/M 
Used-Mem 
Used-Tmp 


Max-Tmp 


* 只 有 当 执 行 统计 打开 时 才 可 用 
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描 述 


对 于 分 布 式 处 理 ， 操 作 使 用 的 DBLINK 的 名 称 

对 于 并 行 处 理 ， 表 队列 用 于 从 属 进 程 之 间 的 通信 

并 行 或 分 布 式 操作 之 间 的 关系 

对 于 并 行 处 理 ， 生 产 者 用 于 向 消费 者 发 送 数 据 的 分 布 规律 


特定 操作 被 执行 的 次 数 。 在 某 些 特别 的 案例 中 , 这 个 统计 显示 的 是 特定 内 存 结 
构 被 访问 的 次 数 (就 像 稍 后 在 10.3.5 节 中 展示 的 一 样 ) 

由 操作 返回 的 实际 行 数 

执行 操作 所 花费 的 实际 时 间 总 和 “(HH:MM:SS.FF) 


在 执行 期 间 通过 逻辑 读 访问 的 块 数量 

在 执行 期 间 通过 物理 读 访 问 的 块 数量 

在 执行 期 间 通 过 物理 写 访问 的 块 数量 

估算 的 最 优化 执行 需要 的 内 存 总 量 〈 按 字 节 ) 

估算 的 一 次 路 径 执行 需要 的 内 存 总 量 〈 按 字 节 ) 

通过 optimal/one-pass/multipass 模 式 执行 的 次 数 

操作 在 最 后 一 次 执行 期 间 使 用 的 内 存 总 量 ( 按 字 节 ) 

操作 在 最 后 一 次 执行 期 间 使 用 的 临时 空间 总 量 ( 按 千 字 节 ) 。 这 个 值 必须 乘 以 
1024 才 能 与 其 他 内 存 使 用 量 的 列 保持 一 致 ( 例 如 ，32 KK 代 表 32 MB ) 

操作 使 用 的 临时 空间 最 高 总 量 ( 按 千 字 节 ) 。 这 个 值 必须 乘 以 1024 才 能 与 其 他 
内 存 使 用 量 的 列 保持 一 致 ( 例 如 ，32 K 代 表 32 MB) 


下 面 的 部 分 展示 了 查询 块 名 称 和 对 象 别名 : 


Query Block Name / Object Alias (identified by operation id): 


- SEL$1 


1 

3 - SEL$1 / T2@SEL$1 
4 - SEL$1 / T2@SEL$1 
5 - SEL$1 / T1QSEL$1 


对 于 执行 计划 中 的 每 一 步 操 作 ， 可 以 看 到 哪 一 个 查询 块 是 与 它 关 联 的 , 或 者 是 在 哪个 对 象 上 执行 
的 。 当 SQL 语句 多 次 引用 同一 张 表 时 ， 这 个 信息 就 至 关 重 要 了 。 查 询 块 名 称 将 会 在 第 11 章 中 与 hint 一 


同 详细 讲解 。 


第 四 部 分 展示 hint 的 集合 ， 即 概要 ， 这 应 该 足以 重 现 那个 特别 的 执行 计划 。 需 要 注意 的 是 ， 概 要 
中 并 不 总 是 包含 所 有 必要 的 hint。 第 11 音 会 解释 为 什么 有 些 概要 不 足以 重 现 一 个 执行 计划 ， 并 描述 怎 


样 才 能 存储 并 利用 这 样 的 概要 ， 例 如 存储 概要 和 SQL 计划 基线 : 
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Outline Data 


BEGIN_OUTLINE_DATA 
IGNORE_OPTIM_ EMBEDDED_ HINTS 
OPTIMIZER_ FEATURES ENABLE('11.2.0.4') 
DB_VERSION('11.2.0.4') 
ALL_ROWS 
OUTLINE LEAF(@"SEL41") 
INDEX_RS_ASC(@"SEL$1”"T2"@"SEL$1”("T2"."ID")) 
FULL(@"SEL$1" "T1"@"SEL$1") 
LEADING(@"SEL$1" "T2"@"SEL$1" "T1"@"SEL$1") 
USE_HASH(@"SEL$1" "T1"@"SEL$1") 
END_OUTLINE_DATA 
*/ 
下 面 这 部 分 只 有 在 查询 优化 器 利用 绑 定 变量 扫 视 时 才 会 显示 出 来 。 其 中 提供 了 每 个 绑 定 变 量 的 数 
据 类 型 和 值 : 


Peeked Binds (identified by position): 


1 - :T1 ID (NUMBER): 6 
2 - :T2 ID MIN (NUMBER): 6 
3 - :T2 ID MAX (NUMBER): 19 
下 面 的 部 分 显示 应 用 了 哪个 谓词 .对 于 每 个 操作 ,都 显示 了 它们 是 在 哪里 ( 行 号 ) 以 及 如 何 ( access、 
filter 或 storage ) 应 用 的 : 


Predicate Information (identified by operation id): 


1 - filter(:T2 ID MIN<=:T2_ ID MAX) 
2 - access("T1"."N"="T2"."N") 
4 - access("T2"."ID">=:T2_ ID MIN AND "T2"."ID"<=:T2 ID MAX) 
5 - filter("T1"."ID">:T1 ID) 
尽管 访问 谓词 是 用 于 利用 高 效 的 访问 结构 来 定位 数据 行 的 〈 例如， 内 存 中 的 散 列 表 ， 如 操作 2; 
或 一 个 索引 ， 如 操作 4 )， 而 过 滤 谓 词 却 只 有 在 数据 已 经 从 存储 它们 的 结构 中 抽取 出 来 以 后 才 会 应 用 。 
此 外 , 当 使 用 了 Exadata 存 储 服务 器 , 存储 谓词 会 指定 一 个 特殊 的 过 滤器 用 于 减轻 底层 存储 子 系统 的 负 
载 。 注 意 在 这 一 部 分 中 既 会 出 现 SQL 语 句 自身 的 谓词 ， 也 有 可 能 出 现 由 查询 优化 器 或 虚拟 私有 数据 库 
( VPD ) 策略 产生 的 谓词 。 在 上 面 的 例子 中 ,你 看 到 以 下 谓词 。 
口 第 1 行 的 操作 检查 绑 定 变量 的 值 是 否 会 导致 空 结 果 集 。 只 有 满足 :T2_ID_MIN<=:T2_ID_MAX 谓 词 
时 ， 查 询 才能 返回 数据 。 如 果 没有 满足 这 个 谓词 ， 就 不 会 执行 查询 操作 的 其 余 动作 。 
口 第 2 行 的 散 列 联接 使 用 "T1"."N"="T2"."N" 谓 词 来 联接 两 个 表 。 换 句 话 说 , 访问 谓词 也 有 可 能 出 
现在 联接 条 件 上 。 具体 在 这 个 例子 中 , 访问 谓词 用 于 指定 内 存 中 包含 t1 表 数据 的 散 列 表 , 其 散 
列 键 为 t1.n, 是 通过 由 访问 t2 表 返回 的 列 t2.n 的 值 来 探测 的 ( 散 列 联接 的 工作 机 制 将 会 在 第 14 
章 中 详细 讨论 )。 
口 第 4 行 的 索引 扫描 访问 了 t_pk 索 引 来 查找 t4 表 的 id 列 。 在 本 例 中 ,访问 谓词 出 现在 查找 执行 的 键 上 。 
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口 在 第 5 行 , t1 表 中 的 所 有 行 都 通过 一 次 全 表 扫 描 读 取出 来 。 然后 , 将 数据 行 从 块 中 抽取 出 来 时 ， 
"T1"."ID">:T1_ID 谓 词 应 用 于 这 些 行 上 。 
下 面 的 部 分 显示 了 执行 所 有 操作 时 会 将 哪些 列 作为 输出 返回 。 以 下 是 摘录 : 


Column Projection Information (identified by operation id): 


1 = "T2"."N"[NUMBER,22], "T2"."ID"[NUMBER,22], "T2"."PAD"[VARCHAR2,1000] 
2 - (#keys=1)"T2"."N" [NUMBER,22], "T2"."ID"[NUMBER,22], 

"T2",."PAD" [VARCHAR2,1000] 
3 - "T2"."ID"[NUMBER,22], "T2"."N"[NUMBER,22], "T2"."PAD"[VARCHAR2,1000] 


4 - "T2".ROWID[ROWID,10], "T2"."ID"[NUMBER,22] 
5 - "T1"."N"[NUMBER,22] 
在 本 例 中 , 千 万 要 注意 , 第 3 行 的 表 访 问 返回 了 id、n 和 pad 列 ， 而 第 5 行 的 表 访 问 只 返回 了 n 这 一 个 
列 。 基 于 这 个 原因 ,估算 的 由 第 3 行 操作 返回 的 每 一 行 (7392/14= 528 字 节 ) 数据 总 量 〈 按 字 节 ) 要 比 
第 5 行 操作 返回 的 (22 776/876=26 字 节 ) 大 得 多 。 第 16 章 会 讲述 更 多 关于 数据 库 引擎 部 分 读 取 一 行 的 
能 力 ， 以 及 为 何 从 性 能 的 角度 来 看 ， 这 样 做 是 合理 的 。 
最 后 ， 有 一 部 分 提供 了 关于 优化 阶段 、 环 境 或 SQL 语句 本 身 的 提醒 和 警告 : 
Note ; 


- dynamic sampling used for this statement (level=2) 


此 处 通知 你 查询 优化 器 使 用 了 动态 采样 来 收集 对 象 统计 信息 。 
10.2.2 display 函数 


display 函 数 返回 计划 表 中 存储 的 执行 计划 。 返回 值 是 dbms_xplan_type_table 集 合 的 实例 。 集 合 的 
元 素 是 dbms_xplan_type 对 象 类 型 的 实例 。 这 种 对 象 类 型 的 唯一 属性 ， 即 plan_table_output， 其 类 型 是 
VARCHAR2 ( 300)。 此 函数 有 以 下 输入 参数 。 

口 table_name 指 定 计划 表 的 名 称 。 默 认 值 是 plan_table 。 如 果 指 定 了 NULL， 则 使 用 默认 值 。 

口 statement id 指定 SQL 请 句 的 名 称 ， 当 执行 EXPLAIN PLAN 语句 的 时 候 ， 作 为 一 个 可 选 参数 给 出 。 
默认 值 是 NULL。 如 果 使 用 了 默认 值 ， 则 显示 最 近 一 次 插入 计划 表 的 执行 计划 (如果 没 有 指定 
filter preds 参 数 )。 

口 format 指 定 在 输出 中 提供 哪些 信息 ,可 以 使 用 基本 值 ( basic typical serial、all 及 advanced )， 
想 要 精细 控制 , 可 以 向 它们 添加 额外 的 修饰 符 ( adaptive、alias、 bytes、 cost、 note、 outline、 
parallel、 partition、 peeked binds、 predicate、projection、remote、report 及 rows )。 如 果 
有 应 该 添加 的 信息 ， 可 以 选择 使 用 + 这 个 字符 作为 前 缀 的 修饰 符 ( 例如，basic +predicate )。 
如 果 有 应 该 移 除 的 信息 ， 可 以 选择 使 用 -这 个 字符 作为 前 缀 的 修饰 符 (例如 ,typical -bytes )。 
可 以 同时 指定 多 个 修饰 符 (例如 ，typical +alias -bytes -cost )。 表 10-2 和 表 10-3 分 别 完整 描 
述 了 基本 值 和 修饰 符 。 默 认 值 是 typical。 

口 filter_preds 指 定 查询 计划 表 时 应 用 的 限制 条 件 。 此 限制 条 件 为 基于 计划 表 中 的 一 个 列 的 常规 


SQL 谓词 ( 例如 ，statement_id =“'test3' )。 默 认 值 是 NULL。 如 果 使 用 了 默认 值 ， 则 会 显示 最 
近 一 次 插入 到 计划 表 的 执行 计划 。 
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表 10-2 ”format 参 数 接受 的 基本 值 


值 描 述 
basic 只 显示 最 少 的 信息 量 ， 基 本 上 只 有 操作 和 执行 所 针对 的 对 象 
typical 显示 最 常见 的 信息 ， 基 本 上 包含 所 有 的 信息 ， 除 了 别名 、 概 要 、 扫 视 的 绑 定 变量 、 子 计划 、 列 
投影 以 及 报告 模式 信息 
serial 与 typical 类 似 ， 除 了 关于 并 行 处 理 的 信息 没有 显示 
all 显示 除了 概要 、 扫 视 的 绑 定 变 量 、 子 计划 以 及 报告 模式 信息 以 外 的 所 有 可 用 信息 
advanced 显示 除了 子 计 划 和 报告 模式 信息 之 外 的 所 有 可 用 信息 
表 10-3 ”format 参 数 接受 的 修饰 符 
值 描 述 
adaptive 控制 子 计划 的 显示 。 这 部 分 在 之 前 的 例子 中 没有 展示 过 ， 可 参考 本 章 稍 后 的 10.3.9 节 。 这 个 修 
饰 符 仅 从 12.1 版 本 开始 才 可 用 
alias 控制 包含 查询 块 名 称 和 对 象 别名 部 分 的 显示 
bytes 控制 执行 计划 表 中 Bytes 列 的 显示 
cost 控制 执行 计划 表 中 Cost 列 的 显示 
note 控制 包含 注释 部 分 的 显示 
outline 控制 包含 概要 部 分 的 显示 
parallel 控制 并 行 处 理 信息 的 显示 ， 特 别 是 指 执行 计划 表 中 的 TQ、IN-0UT 和 PQ Distrib 列 。 这 些 列 在 之 
前 的 例子 中 没有 显示 过 
partition 控制 分 区 信息 的 显示 ， 明 确 地 说 是 执行 计划 表 中 的 Pstart 和 Pstop 列 。 这 些 列 在 之 前 的 例子 中 
没有 显示 过 
peeked binds 控制 包含 扫 视 的 绑 定 变量 部 分 的 显示 。 
predicate 控制 包含 过 滤 谓 词 、 访 问 谓词 和 存储 谓词 的 部 分 的 显示 
projection 控制 包含 列 投影 信息 的 部 分 的 显示 
remote 控制 远程 执行 的 SQL 语 名 的 显示 。 这 部 分 在 之 前 的 例子 中 没有 显示 
report 控制 报告 模式 的 激活 。 启 用 时 ,关于 自 适应 和 重新 优化 执行 计划 的 额外 信息 就 会 显示 出 来 。 这 
部 分 在 之 前 的 例子 中 没有 显示 ， 可 参见 10.3.9 节 。 这 个 修饰 符 仅 从 12.1 版 本 开始 才 可 用 
IrOws 控制 执行 计划 表 中 Rows 列 的 显示 


要 使 用 display 函 数 ， 调 用 者 只 需要 在 该 包 上 有 EXECUTE 权 限 并 在 计划 表 上 拥有 SELECT 权限 。 

下 面 的 查询 显示 了 相同 的 执行 计划 ， 展 示 了 在 基本 值 basic、typical 以 及 advanced 之 间 的 主要 区 
别 。 以 下 是 对 display.sql 脚 本 生成 输出 的 一 段 摘录 : 

SQL> SELECT * FROM table(dbms xplan.display(NULL, NULL, "basic ' )); 


PLAN_TABLE_OUTPUT 


| Id | Operation | Name | 


| 0 | SELECT STATEMENT | | 
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| SORT AGGREGATE | 
| TABLE ACCESS FULL| T | 


SQL> SELECT * FROM table(dbms xplan.display(NULL, NULL, "typical ' ) ); 


PLAN_TABLE_OUTPUT 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time 

| 0 | SELECT STATEMENT | | 1 | 过 . | 2 (0)| 00:00:01 | 
| 1| SORT AGGREGATE | [国生 4 | | | 
|* 2 | TABLE ACCESS FULL| T | 下 | 60 | 2 (0)| 00:00:01 | 


2 - filter("N"<=19 AND "N">=6) 2 
SOL> SELECT * FROM table(dbms xplan.display(NULL, NULL, 'advanced')); 


PLAN_ TABLE OUTPUT 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time 

| 0 | SELECT STATEMENT | | :| 4 | 2 (0)| 00:00:01 | 
| 1 | SORT AGGREGATE | | i | 4 | | 

|* 2 | TABLE ACCESS FULL| T [| 六 有 | 60 | 2 (0)| 00:00:01 | 


1 - SEL$1 
2 - SEL$1 / TQ@SEL$1 


Outline Data 


BEGIN OUTLINE_DATA 
FULL(@"SEL$1" "T"@"SEL$1") 
OUTLINE LEAF(@"SEL$1") 
ALL_ ROWS 
DB_VERSION('11.2.0.3') 
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OPTIMIZER_FEATURES_ENABLE('11.2.0.3') 
IGNORE_OPTIM_EMBEDDED_HINTS 
END_OUTLINE_DATA 

*/ 


Predicate Information (identified by operation id): 


2 - filter("N"<=19 AND "N">=6) 


Column Projection Information (identified by operation id): 
1 - (#keys=0) COUNT(*)[22] 

下 面 的 查询 展示 了 如 何 使 用 修饰 符 从 基本 值 basic 和 typical 生 成 的 默认 输出 中 添加 或 移 除 信息 。 
因为 它们 基于 与 之 前 例子 相同 的 查询 ， 你 可 以 对 比 输出 结果 来 查看 有 何不 同 之 处 。 以 下 是 一 段 来 自 
display.sql 脚 本 输出 的 摘录 : 

SQL> SELECT * FROM table(dbms xplan.display(NULL, NULL, "basic +predicate')); 


PLAN_TABLE_OUTPUT 


| Id | 0peration | Name | 


0 | SELECT STATEMENT | | 
| 1| SORT AGGREGATE | | 
2 | TABLE ACCESS FULLI T | 


2 - filter("N"<=19 AND "N">=6) 
SQL> SELECT * FROM table(dbms xplan.display(NULL, NULL, "typical -bytes -note')); 


PLAN_TABLE_OUTPUT 


| Id | Operation | Name | Rows | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 | 
| 1 | SORT AGGREGATE | | 1 | | 

|* 2 | TABLE ACCESS FULL| T 国力 2 (0)| 00:00:01 | 
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Predicate Information (identified by operation id): 


2 - filter("N"<=19 AND "N">=6) 


将 current_schema 会 话 参 数 设置 为 一 个 拥有 默认 名 称 的 计划 表 的 模式 时 ,如 果 你 使 用 EXPLAIN PLAN 
语句 和 display 函 数 ， 则 必须 在 EXPLAIN PLAN 语 句 的 INTO 子 句 中 和 display 消 数 的 table_name 参 数 中 加 入 
该 模式 名 称 。 如 果 不 这 么 做 就 会 导致 display 函 数 引 发 一 个 错误 。 下 面 的 例子 演示 了 该 行为 : 


SQL> ALTER SESSION SET current schema = franco; 
SQL> EXPLAIN PLAN FOR SELECT * FROM t; 
SQL> SELECT * FROM table(dbms xplan.display); 


PLAN_TABLE_OUTPUT 


Error: cannot fetch last explain plan from PLAN TABLE 
SOL> EXPLAIN PLAN INTO franco.plan table FOR SELECT * FROM t; 
SOL> SELECT * FROM table(dbms xplan.display(table name=>'franco.plan table')); 


PLAN_TABLE_OUTPUT 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | 14 | 1218 | 3 (0)| 00:00:01 | 
| 4 | ”TABLE ACCESS FULL| T | 14 | 1218 | 3 (0)| 00:00:01 | 


通过 display 函 数 也 可 以 查询 一 张 拥 有 基于 v$sql _ plan_statistics al1 视 图 结构 的 计划 表 。 在 想 要 
保存 那些 被 有 意 设 计 为 只 在 库 缓 存 中 短暂 存在 的 信息 时 ， 这 个 特性 就 派 上 用 场 了 。 因 为 这 样 的 计划 表 
中 包含 额外 的 信息 ， 当 通过 display 函 数 查询 它 时 ，format 参 数 支 持 接 下 来 的 部 分 描述 的 额外 修饰 符 ， 
详 见 表 10-4。 下 面 的 例子 展示 了 如 何 利用 这 个 特性 保存 关于 执行 最 后 一 条 SQL 语句 时 的 信息 : 


SOL> SELECT /*+ gather plan statistics */ count(*) FROM 七 ; 


COUNT(*) 


SOL> CREATE TABLE my plan table 

AS 

SELECT cast(1 AS VARCHAR2(30)) AS plan id, p.* 

FROM v$sql plan statistics all p 

WHERE (sql id, child number)= (SELECT prev_sql id, prev child number 
FROM v$session 


人 


Cn 人 
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7 WHERE sid = sys_ context('userenv','sid')); 
SQL> SELECT * FROM table(dbms xplan.display('my plan table'’, NULL, 'iostats')); 


PLAN TABLE OUTPUT 


| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | 
| 0 | SELECT STATEMENT | | 2 | | 2 |00:00:00.01 | 10 | 4 | 
| 1 | SORT AGGREGATE | | | 1 | 2 |00:00:00.01 | 10 | 4 | 
| 2| TABLE ACCESS FULL| T | 2| 1000 | 2000 |00:00:00.01 | 10 | 4 | 


allstats 


iostats 


last 


memstats 


rowstats 


runstats last 


runstats tot 


表 10-4 format 参 数 接受 的 修饰 符 


描 ” 述 
这 是 iostats memstats 的 简写 
控制 运行 时 统计 信息 的 显示 ( 列 Starts、A-Rows、A-Time) 、 估 算 的 行 数列 E-Rows) 以 及 磁盘 IO 
统计 信息 ( 列 Buffers、Reads、Writes) 
默认 情况 下 ，allstats、iostats、memstats 和 rowstats 修 饰 符 都 会 显示 所 有 执行 的 累积 统计 信息 。 
如 果 将 这 个 值 加 入 它们 ， 则 仅 会 显示 最 后 一 次 执行 的 统计 信息 。 为 并 行 处 理 的 SQL 语 句 指定 的 这 
个 修饰 符 可 能 并 不 会 像 你 期 望 的 那样 工作 。 关 于 这 方面 的 更 多 信息 请 参考 15.3 节 
控制 内 存 使 用 的 统计 信息 的 显示 ( 列 OMem、1Mem、0/1/M、Used-Mem、Used-Tmp、 和 Max-Tmp) 
控制 行 计数 统计 信息 的 显示 ( 列 Starts。E-Rows 和 A-Rows) 。 这 个 修饰 符 仅 从 11.2.0.4 版 本 开始 才 
可 用 
与 iostats last 一 样 。 这 个 参数 已 经 不 推荐 使 用 ， 并 只 是 为 了 向 后 兼容 而 提供 
和 iostats 一 样 。 这 个 参数 已 经 不 推荐 使 用 ， 并 只 是 为 了 向 后 兼容 而 提供 


10.2.3 display cursor 函数 


display_cursor 国 数 返回 库 缓 存 中 存储 的 执行 计划 。 注 意 ， 在 Real Application Clusters 环 境 中 ， 是 
无 法 获得 远 端 实例 中 存储 的 执行 计划 的 。 与 display 函 数 一 样 , 其 返回 值 是 dbms xplan_ type _ table 集合 
的 实例 。 该 函数 的 输入 参数 如 下 所 示 。 


口 sql_id 指 定 返 回 的 执行 计划 的 父 游标 。 上 默认 值 是 NULL。 如 果 使 用 了 默认 值 ， 就 会 返回 当前 会 i 
执行 的 最 后 一 个 SQL 语 句 的 执行 计划 。 

口 cursor_child_no 指 定子 游标 号 ， 它 与 sql_id 一 起 ,确定 返回 哪个 子 游标 的 执行 计划 。 上 默认 值 
是 0。 如 果 指 定 了 NU11， 则 会 返回 sql id 参数 指定 的 父 游标 下 的 所 有 子 游标 。 

口 format 指 定 显示 哪些 信息 。 支 持 的 值 与 display 函 数 的 format 参 数 支持 的 值 相 同 。 此 外 ， 如 果 
可 以 访问 执行 统计 信息 〈 换 句 话 说， 如 果 将 statistics level 初始 化 参数 设置 为 al1 或 在 SQL 
语句 中 指定 了 gather plan_statistics 这 个 hint )， 那 么 表 10-4 中 描述 的 修饰 符 也 同样 受 支 持 。 
默认 值 为 typical。 
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警告 ”正如 第 2 章 中 指出 的 那样 ， 有 时 候 v$sql 视 图 中 的 sql_id 和 child_number 列 并 不 足以 确定 一 个 子 
游标 。 在 这 种 情况 下 ， 因 为 bug 14585499， 并 且 在 11.2.0.3 及 之 前 的 版 本 中 ，display_cursor 函 
数 会 返回 错误 的 数据 。 要 识别 出 这 个 问题 ， 请 在 display_cUrsor 的 输出 中 查找 以 下 错误 信息 : 


An uncaught error happened in prepare sql statement : ORA-01422: exact fetch returns more than 
requested number of rows 


可 以 通过 display_cursor ora-01422.5ql 脚 本 来 重 现 这 个 bug。 


要 使 用 display_cursor 函 数 ， 调 用 者 需要 在 以 下 动态 性 能 视图 上 拥有 SELECT 权 限 : v$session、 
v$sql 、v$sql plan 以 及 v$sql plan statistics all。 其 中 select catalog role 角 色 和 select any 
dictionary 系 统 权限 提供 了 这 些 权 限 。 


注意 表 10-4 中 列举 的 修饰 符 对 于 与 查询 优化 器 估算 有 关 的 以 下 列 有 移 除 的 副作用 : Bytes、TempSpc、 
Cost (%CPU) 、Time。 如 果 你 希望 其 中 一 列 出 现在 输出 中 ,必须 通过 基本 值 或 修饰 符 明 确 指定 。 


下 面 的 例子 展示 一 个 查询 使 用 hint gather plan_statistics 来 启用 执行 统计 信息 的 生成 。 然 后 会 通 
知 display_cursor 函 数 显示 最 后 一 次 执行 的 磁盘 IO 统计 信息 。 因 为 没有 物理 读 或 写 发 生 ， 所 以 仅 会 显 
示 逻 辑 读 ( Buffers )。 以 下 是 一 段 来 自 display_cursor.sql 脚 本 输出 的 摘录 : 


SQL> SELECT /#+ gather plan statistics */ count(pad) 
2 FROM (SELECT rownum AS rn, pad FROM t ORDER BY n) 
3 WHERE rn = 1; 


COUNT (PAD) 


1 
SQL> SELECT * FROM table(dbms xplan.display cursor('d5vodt28fp5fh', 0, 'iostats last')); 


PLAN_TABLE_OUTPUT 


SELECT /*+ gather plan statistics */ count(pad) FROM (SELECT rownum AS 
rn, pad FROM 七 ORDER BY n)WHERE rn = 1 


Plan hash value: 2545006537 


| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | 
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.02 | 147 | 
| 1 | SORT AGGREGATE | | 1 | 和 | 1 |00:00:00.02 | 147 | 
|* 2 | VIEW | | 1| 1000 | 1 |00:00:00.02 | 147 | 
1 ¥il SORT ORDER BY | | 1| 1000 | 1000 |00:00:00.02 | 147 | 
E | COUNT | | | | 1000 |00:00:00.01 | 145 | 
E 5| TABLE ACCESS FULL| T | 1| 1000 | 1000 |00:00:00.01 | 145 | 
上 
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Predicate Information (identified by operation id): 


2 - filter("RN"=1) 


10.2.4 _ display_aw 函数 


display_awr 消 数 返回 AWR 中 存储 的 执行 计划 。 与 display 肾 数 一 样 ， 其 返回 值 是 doms_xplan_ 
type_table 集 合 的 实例 。 该 函数 的 输入 参数 如 下 所 示 。 

口 sql_id 指 定 返 回 哪 条 SQL 语 句 的 执行 计划 。 这 个 参数 没有 默认 值 。 

口 plan_hash_value 指 定 要 返回 的 执行 计划 的 散 列 值 。 默 认 值 是 NULL。 如 果 使 用 了 默认 值 ， 则 会 

返回 所 有 与 sq1_id 参 数 确 定 的 SQL 语句 有 关 的 执行 计划 。 
口 db_ id 指定 应 该 返回 哪个 数据 库 上 执行 的 执行 计划 。 默 认 值 是 NWLL。 如 果 使 用 了 默认 值 ， 则 使 
用 当前 数据 库 。 

口 format 指 定 显示 哪些 信息 。 尽 管 在 display 函 数 的 format 参 数 中 使 用 的 值 也 同样 受 支 持 ， 但 并 
不 是 所 有 的 信息 都 能 够 显示 出 来 。 举 例 来 说 ， 因 为 AWR 不 存储 有 关 谓 词 的 信息 ， 所 以 输出 中 
缺少 这 部 分 。 默 认 值 是 typical。 

要 使 用 display_awr 函 数 ， 调 用 者 至 少 应 在 以 下 数据 字典 视图 上 拥有 SELECT 权 限 : dba_hist sql_ 
plan 和 dba_hist_sqltext 。 如 果 使 用 了 db _ id 参数 ， 还 需要 v$database 视 图 上 的 SELECT 权限 。 其 中 
select catalog _ role 角色 提供 了 这 些 权 限 。 

下 面 的 查询 展示 了 对 于 一 个 给 定 的 SQL 语句 存在 多 个 执行 计划 时 plan_hash_value 参 数 的 用 途 。 注 
意 第 一 个 查询 返回 了 两 个 执行 计划 ， 而 第 二 个 查询 只 返回 了 一 个 。 以 下 是 一 段 来 自 display_awr.sql 
脚本 输出 的 摘录 : 


SQL> SELECT * FROM table(dbms xplan.display awr('48vuyqjwpf9wg', NULL, NULL, 'basic')); 


PLAN_TABLE_OUTPUT 


SELECT COUNT(N) FROM T 


Plan hash value: 2966233522 


| Id | 0peration | Name | 
0 | SELECT STATEMENT | | 
| 1| SORT AGGREGATE | 
2 | TABLE ACCESS FULL| T | 


SELECT COUNT(N) FROM T 
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Plan hash value: 3776247601 


0 | SELECT STATEMENT | | 
| 1 | SORT AGGREGATE | 
2 | INDEX FAST FULL SCAN| I | 


SQL> SELECT * FROM table(dbms xplan.display awr('48vuyqjwpf9wg', 2966233522, NULL, 'basic')); 


PLAN_TABLE_OUTPUT 


SELECT COUNT(N) FROM T 
Plan hash value: 2966233522 


| 0 | SELECT STATEMENT | 
| 1| SORT AGGREGATE | | 
| 2| TABLE ACCESS FULLIT | 


有 几 种 情况 会 导致 一 个 给 定 的 SQL 请 名 存在 多 个 执行 计划 ， 比 如 添加 了 一 个 索引 或 者 只 是 因为 数 
据 ( 并 且 进 而 其 对 象 统计 信息 ) 发 生 了 变化 。 基 本 上 ,每 次 查询 优化 融 执 化 的 环境 发 生变 化 ,都 可 能 
会 生成 不 同 的 执行 计划 。 当 你 对 一 条 SQL 语句 的 性 能 产生 疑问 ， 而 且 认为 该 SQL 在 之 前 一 段 时 间 内 的 
运行 都 没有 问题 时 ， 这 样 的 输出 就 有 用 处 了 。 思 路 是 ,检查 经 过 一 段 时 间 后 ， 是 否 使 用 了 多 个 执行 计 
划 执 行 过 该 SQL 语句 。 如 果 是 这 样 ， 基 于 可 用 的 信息 推断 导致 这 种 变化 的 原因 可 能 是 什么 。 
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我 总 是 很 惊讶 关于 如 何 阅读 执行 计划 的 文档 是 如 此 之 少 ， 甚 至 好 像 有 很 多 人 无 法 正确 阅读 它们 。 
在 这 里 我 尝试 通过 描述 我 阅读 执行 计划 时 使 用 的 方法 来 解决 这 个 问题 。 注 意 这 里 不 会 提供 关于 不 同 操 
作 的 细节 ， 而 是 会 提供 所 需要 的 基础 知识 ， 以 便于 理解 如 何 阅 读 执行 计划 。 我 会 在 第 四 部 分 给 出 关于 
大 部 分 常见 操作 的 详细 信息 。 


警告 并 行 处 理会 使 执行 计划 的 解释 更 加 困难 。 原 因 很 简单 : 多 个 操作 并 发 执行 。 为 了 保持 叙述 
尽 可 能 简单 ， 本 节 并 不 涵盖 并 行 处 理 的 内 容 。 关 于 并 行 处 理 执行 计划 的 信息 会 在 第 15 章 中 
提供 
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10.3.1 父 - 子 关 系 


执行 计划 是 一 棵 树 ， 用 来 描述 SQL 引擎 执行 操作 的 顺序 以 及 各 个 操作 之 间 的 关系 。 树 中 的 每 个 节 
点 是 一 个 行 源 操作 ( 实际 上 是 作为 用 C 语 言 编 写 的 一 个 函数 执行 的 )， 例 如， 表 扫 描 、 联 接 或 排序 。 在 
各 操作 (节点 ) 之 间 , 存在 着 父子 关系 。 理 解 这 些 关系 对 于 正确 阅读 执行 计划 非常 关键 。 当 执行 计划 
以 文本 格式 显示 时 ， 控 制 父 - 子 关系 的 规则 如 下 所 示 。 
口 一 个 父 操作 拥有 一 个 或 多 个 子 操作 。 
口 一 个 子 操作 只 有 一 个 父 操作 。 
口 唯一 没有 父 操 作 的 操作 是 树 的 根 操 作 ( 顶层 操作 )。 
口 子 操作 跟随 着 它们 的 父 操作 ， 在 右 侧 缩 进 排 列 。 依 赖 于 显示 执行 计划 使 用 的 方法 ， 缩 进 可 以 
是 一 个 空格 字符 、 两 个 空格 或 其 他 什么 。 这 真 的 不 重要 。 关 键 是 同一 个 父 操作 下 的 所 有 子 操 
作 都 拥有 相同 的 缩 进 。 
口 父 操 作 在 子 操作 之 前 出 现 ( 父 操作 的 ID 比 子 操作 的 ID 要 小 )。 如 果 一 个 子 操作 前 面 有 多 个 与 父 
操作 一 样 缩 进 的 操作 ， 则 距离 最 近 的 操作 为 父 操作 。 
接 下 来 是 一 个 由 relationship.sql 脚 本 生成 的 样 例 执 行 计 划 。 注意 ， 尽 管 只 有 0peration 列 需要 贯 
穿 整个 执行 计划 ，Id 列 出 现在 这 里 是 为 了 帮助 你 更 容易 地 标识 操作 。 用 来 生成 它 的 SQL 语句 被 有 意 忽 
略 掉 ， 因 为 它 并 不 服务 于 本 节 的 内 容 : 


| Id | 0peration Name | 
| 0 | UPDATE STATEMENT | 
| 1 | UPDATE tr | 
| 2| NESTED LOOPS | 
| 3| TABLE ACCESS FULL TE 
| 4| INDEX UNIOUE SCAN T Pk | 
| 5 | SORT AGGREGATE | 
| 6 | ~ TABLE ACCESS BY INDEX ROWID| T | 
1 六 INDEX FULL SCAN xI | 
| 8 | TABLE ACCESS BY INDEX ROWID | T | 
| 9| INDEX UNIOUE SCAN |TRKI| 


图 10-2 提 供 了 执行 计划 的 图 示 。 使 用 之 前 描述 的 规则 ， 你 可 以 推断 出 以 下 内 容 。 

口 操作 0 是 这 棵 树 的 根 。 它 告知 你 执行 计划 关联 的 SQL 语句 的 类 型 。 操 作 0 有 一 个 子 操作 : 操作 1 
口 操作 1 有 三 个 子 操作 : 2、5， 还 有 8。 

口 操作 2 有 两 个 子 操作 : 3 和 4。 

口 操作 3 和 4 没有 子 操作 。 

口 操作 5 有 一 个 子 操作 : 6。 

口 操作 6 有 一 个 子 操作 : 7。 

口 操作 7 没有 子 操作 。 

口 操作 8 有 一 个 子 操作 : 9。 

口 操作 9 没有 子 操作 。 
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图 10-2 ”执行 计划 操作 之 间 的 父 - 子 关系 


了 解 父 - 子 关系 对 于 理解 执行 计划 执行 各 个 操作 的 顺序 十 分 关键 。 实际 上 ,为 了 完成 它们 的 任务 ， 
父 操作 需要 由 它们 的 子 操作 提供 的 数据 。 因 此 ， 虽 然 执行 是 从 树 的 根部 开始 的 ， 第 一 个 被 完全 执行 的 
操作 是 没有 子 操作 的 那个 , 所 以 , 是 树 的 叶 节 点 。 为 验证 这 一 点 , 我 们 看 一 下 接 下 来 的 这 个 执行 计划 : 


| 0 | SELECT STATEMENT | 
| 1 | SORT ORDER BY | 
| 2| TABLE ACCESS BY INDEX ROWID| 
| 3| INDEX RANGE SCAN | 


操作 按 以 下 顺序 执行 。 

(1) 执行 计划 的 入 口 点 是 操作 0, 它 是 树 的 根 操作 。 但 是 , 操作 0 是 一 个 SELECT 语 句 ， 没 有 数据 可 供 
操作 。 因 此 ， 它 必须 调用 它 的 子 操作 (1)。 

(2) 操作 1 是 一 个 排序 操作 ， 没 有 数据 可 供 操作 。 因 此 ， 它 必须 调用 它 的 子 操作 (2)。 

(3) 操作 2 是 一 个 表 扫描 ， 需 要 rowid 来 访问 t 表 。 因 此 ， 它 必须 调用 它 的 子 操作 (3)。 


(4) 操作 3 是 一 个 索引 扫描 , 不 需要 来 自 其 他 操作 的 数据 ( 它 没有 子 操作 )。 因此, 它 在 t_pk 索 引 上 


执行 索引 范围 扫描 并 将 它 找到 的 rowid 传 递 给 父 操作 (2)。 
(5) 操作 2 使 用 从 它 的 子 操作 (3) 接 收 的 rowid 列 表 去 访问 t 表 。 然 后 ， 将 结果 数据 传递 给 它 的 父 操 
作 (1): 
(6) 操作 1 对 它 的 子 操作 (2) 传 递 过 来 的 数据 进行 排序 ， 然 后 将 排序 后 的 数据 传递 给 它 的 父 操作 (0)。 
(7) 操作 0 将 从 它 的 子 操作 (1) 接 收 的 数据 传递 给 调用 者 。 


注意 尽管 第 一 个 被 执行 的 操作 永远 是 树 的 根 操作 ,但 是 父 操作 ( 上面 的 例子 中 是 三 个 ) 可 能 除了 


调用 子 操作 以 外 什么 都 不 做 。 所 以 ， 为 简单 起 见 ， 我 通常 会 说 执行 是 从 第 一 个 做 实际 工作 的 
操作 ( 上 面 的 例子 中 是 操作 3 ) 开始 的 
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下 面 的 三 条 通用 规则 总 结 了 刚刚 描述 的 行为 。 
口 父 操作 调用 子 操作 。 

口 子 操作 在 它们 的 父 操作 之 前 被 完全 执行 。 
口 子 操作 向 它们 的 父 操作 传递 数据 。 


10.3.2 ”操作 的 类 型 


有 几 百 种 不 同 的 操作 。 当 然 了 ,要 完全 理解 一 个 执行 计划 ， 你 应 该 知道 每 一 个 操作 都 是 用 来 做 什 
么 的 。 出 于 我 们 完成 整个 执行 计划 的 目的 , 你 只 需要 考虑 四 种 主要 类 型 的 操作 : 独立 操作 、 选 代 操作 、 
无 关联 组 合 操作 以 及 关联 组 合 操作 。 基 本 上 ， 每 种 类 型 都 有 特定 的 行为 ， 而 了 解 这 种 行为 就 足够 阅读 
执行 计划 了 。 


警告 ”我 是 在 2007 年 编写 关于 查询 优化 器 的 演示 文稿 时 ， 提 出 了 此 处 使 用 的 四 种 操作 类 型 的 术语 。 
别 指望 能 在 其 他 地 方 找到 这 些 术 语 。 


除了 这 四 种 类 型 之 外 ,还 可 以 将 操作 分 为 阻塞 操作 和 非 阻塞 操作 。 简 单 来 说 ， 阻 塞 操作 批量 处 理 
数据 ， 非 阻塞 操作 逐 行 处 理 数 据 。 举 例 来 说 ， 排 序 操 作 是 阻塞 的 ， 因 为 只 有 当 所 有 输入 行 都 被 完全 处 
理 (排序 ) 后 才能 返回 和 输出 的 行 , 因为 第 一 个 输出 行 可 能 出 现在 输入 数据 集 的 任何 地 方 。 而 另 一 方面 ， 
应 用 简单 限制 条 件 的 过 滤器 是 非 阻 塞 的 ， 因 为 它 单 独 验 证 每 一 行 。 很 显然 对 于 阻塞 操作 ， 必 须 将 数据 
缓存 到 内 存 中 ( PGA ) 或 磁盘 上 ( 临时 表 空 间 )。 为 简单 起 见 ， 在 完成 一 个 执行 计划 时 ， 你 可 以 认为 
所 有 的 操作 都 是 阻塞 操作 。 但 是 记 住 ， 大 多 数 的 操作 实际 上 是 非 阻 塞 的 ， 而 且 出 于 明显 的 原因 ，SQL 
引擎 会 尝试 尽 可 能 地 避免 缓存 数据 。 


10.3.3 ”独立 操作 


我 将 最 多 拥有 一 个 子 操作 的 所 有 非 迭 代 操 作 ( 和 迭 代 操 作 将 在 下 一 节 介 绍 ) 视 为 独立 操作 。 大 部 分 
操作 都 是 独立 的 。 这 使 得 执行 计划 的 解释 变 得 更 容易 , 因为 只 有 不 到 24 种 操作 不 属于 这 种 类 型 。 控 制 
独立 操作 运行 的 规则 除了 10.3.1 节 中 描述 的 规则 之 外 ， 还 有 下 面 这 条 规则 : 

口 一 个 子 操作 最 多 被 执行 一 次 。 

下 面 是 一 个 查询 和 它 的 执行 计划 的 例子 ， 基 于 stand-alone.sql 脚 本 生成 的 输出 ( 图 10-3 提 供 了 关 
于 它 的 父 - 子 关系 的 图 形 表示 ): 

SELECT deptno, count(*) 

FROM emp 


WHERE job = 'CLERK' AND sal “ 1200 
GROUP BY deptno 


0 | SELECT STATEMENT | | 纪 二 5 和 
1 | HASH GROUP BY | | a 2 | 
2 | TABLE ACCESS BY INDEX ROWID| EMP | 4 3 
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2 - filter("SAL"<1200) 
3 - access("]0B"='CLERK') 


图 10-3 ”独立 操作 之 间 的 父 - 子 关系 


这 个 执行 计划 仅 由 独立 操作 组 成 。 通过 应 用 之 前 描述 的 规则 ， 你 会 发 现 执行 计划 按照 以 下 方式 执 
行 操作 。 

(1) 操作 0、 操 作 1 和 操作 2 都 有 一 个 单独 的 子 操作 ( 分 别 是 1、2 和 3 ); 它们 不 可 能 是 最 先 执行 的 操 
作 。 因 此 ， 执 行 从 操作 3 开始 。 

(2) 操作 3 通过 应 用 "Io0B"='CLERK' 访 问 谓 词 来 扫描 emp_job i 索引 。 这 样 做 时 , 它 从 索引 上 抽取 四 个 
rowid ( 此 信息 在 A-Rows 列 中 给 出 ) 并 将 它们 传递 给 它 的 父 操作 (2) 。 

(3) 操作 2 通过 从 操作 3 传递 过 来 的 四 个 rowid 访 问 emp 表 。 对 于 每 个 rowid， 读 取 一 行 数据 。 接 下 
来 ， 它 应 用 "SAL"<1200 过 滤 谓 词 。 这 个 过 滤器 会 排除 掉 一 条 数据 。 余 下 的 三 条 数据 传递 给 它 的 父 操 
作 (1) 。 

(4) 操作 1 在 操作 2 传递 过 来 的 数据 上 执行 一 个 GROUP BY 操作 。 结 果 集 减少 到 两 条 数据 并 传递 给 它 的 
父 操作 (0 )。 

(5) 操作 0 将 数据 发 送 给 调用 者 。 

注意 Starts 列 是 如 何 清晰 地 展示 每 一 个 操作 都 执行 了 一 次 的 。 

其 中 一 条 规则 声明 子 操 作 在 父 操 作 之 前 被 完整 地 执行 。 这 大 体 上 没 错 , 但 是 当 智能 优化 被 引进 来 
时 情况 就 有 些 不 一 样 了 。 可 能 发 生 的 情况 是 ， 父 操作 判断 完全 执行 子 操作 没有 意义 甚至 根本 不 需要 执 
行 它 。 换 名 话说 ， 父 操作 控制 子 操作 的 执行 。 我 们 来 看 两 个 常见 的 案例 。 注 意 ， 两 个 例子 都 摘自 
stand-alone.sql 脚 本 生成 的 输出 。 


1. COUNT STOPKEY 操 作 的 优化 

COUNT STOPKEY 操 作 通 常用 于 执行 top-n 查 询 。 它 的 目标 是 一 旦 所 需 数据 已 经 返回 给 了 调用 者 就 会 停 
止 处 理 。 举 例 来 说 ， 下 面 查询 的 目的 是 只 返回 在 emp 表 中 找到 的 前 10 条 数据 : 

SELECT * 


FROM emp 
WHERE rownum <= 10 


| 0 | SELECT STATEMENT | | 1 | 
|* 1 | COUNT STOPKEY | | 1 | 10 | 
| 2| TABLE ACCESS FULL| EMP | | 
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1 - filter(ROWNUM<=10) 
在 这 个 执行 计划 中 需要 重点 关注 的 是 由 操作 2 返回 的 行 数 被 限制 为 10。 即 使 操作 2 是 对 一 个 包含 超 
过 10 条 数据 ( 实际 上 这 张 表 包 含 14 条 数据 ) 的 表 进 行 全 表 扫 描 也 是 这 样 的。 结果 当 必要 的 行 数 被 处 理 
完毕 后 操作 1 就 停止 了 操作 2 的 处 理工 作 。 但 是 要 小 心 ， 因 为 阻塞 操作 是 无 法 停止 的 。 事 实 上 ， 必 须 在 
它们 向 父 操作 返回 数据 之 前 完全 处 理 它们 。 例 如 ， 在 下 面 的 查询 中 ， 因 为 ORDER BY 子 句 ， 会 读 取 emp 
表 的 所 有 行 ( 14 ): 


SELECT * 
FROM ( 
SELECT 波 
FROM emp 
ORDER BY sal DESC 


WHERE rownum <= 10 


| Id | 0peration | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1 | 10 | 
|* 1 | COUNT STOPKEY | | 1 | 10 | 
| 2| VIEW | | 4 10 | 
|* 3 | SORT ORDER BY STOPKEY| | 1 | 10 | 
| 4| TABLE ACCESS FULL | EMp | 1 | 14 | 


1 - filter(ROWNUM<=10) 
3 - filter(ROWNUM<=10) 


2. FILTER 操 作 的 优化 

FILTER 操 作 不 仅 会 在 它 的 子 操作 向 它 传递 数据 的 时 候 应 用 过 滤 条 件 ， 此 外 ， 它 也 能 决定 完全 避免 
子 操作 以 及 所 有 依赖 的 操作 ( 孙子 操作 等 ) 的 执行 。 例 如 ， 在 下 面 的 查询 中 ， 从 操作 1 处 应 用 的 过 渡 
谓词 检查 绑 定 变量 的 值 是 否 会 导致 空 的 结果 集 。 实 际 上 , 查询 只 有 在 满足 : SAL_MIN<=:SAL_MAX 过 滤 谓 
词 的 情况 下 才 会 返回 数据 : 

SELECT * 


FROM emp 
WHERE sal BETWEEN :sal min AND :sal max 


0 | SELECT STATEMENT | | «1 0 | 
|* 1 | FILTER | | 1 | 0 | 
2 | TABLE ACCESS FULL| EMP | o | 0 | 


1 - filter(:SAL MIN<=:SAL MAX) 
2 - filter(("SAL"<=:SAL MAX AND "SAL">=:SAL MIN)) 


根据 之 前 描述 的 规则 ， 操 作 2 应 该 是 展示 的 执行 计划 中 第 一 个 被 完全 执行 的 操作 。 在 现实 中 ， 查 
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看 Starts 列 后 可 以 知道 只 有 操作 0 和 操作 1 被 执行 了 。 优化 简单 地 避免 了 操作 2 的 处 理 , 因为 数据 无 论 如 
何 也 没有 机 会 通过 操作 1 应 用 的 过 滤 条 件 。 


10.3.4 和 迭代 操作 


我 将 所 有 最 多 拥有 一 个 可 以 多 次 执行 的 子 操作 的 操作 都 视 为 迭代 操作 。 你 可 以 认为 它们 是 在 执行 
计划 中 实现 了 某 种 循环 的 操作 。INLIST ITERATOR 和 大 部 分 拥有 PARTITION 前 缀 的 操作 ( 例如，PARTITION 
RANGE ITERATOR， 关 于 这 些 操作 的 详细 描述 请 参见 第 13 章 ) 都 是 这 种 类 型 的 操作 。 控 制 迭 代 操 作 运 行 
的 规则 除了 之 前 在 10.3.1 节 中 描述 的 规则 之 外 ， 还 有 下 面 这 条 规则 : 

口 子 操作 可 能 会 执行 多 次 ， 也 可 能 根本 不 执行 。 

下 面 是 来 自 iterative.sql 脚 本 输出 的 查询 及 其 执行 计划 的 例子 : 


SELECT 站 
FROM emp 
WHERE job IN ('CLERK', 'ANALYST') 


| Id | 0peration | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | A 1 | 6 | 
| 1 | INLIST ITERATOR | | 1 | 6 | 
| 2| TABLE ACCESS BY INDEX ROWID| EMP | 5 伪 | 6 | 
|* 3 | INDEX RANGE SCAN | EMP JOB I | 2 | 6 | 


3 - access(("]0B"='ANALYST' OR "J0B"='CLERK')) 

这 个 执行 计划 与 之 前 在 独立 操作 中 讨论 的 那个 类 似 , 唯 一 的 区 别 是 执行 计划 的 一 部 分 ,因为 INLIST 
ITERATOR 操 作 的 缘故 ， 可 以 被 执行 多 次 。 明 确 地 说 ， 和 迭代 操作 的 子 操作 可 以 被 执行 多 次 。 在 本 例 中 ， 
操作 2 和 3 为 IN 条 件 中 的 每 个 不 同 值 都 执行 了 一 次 。 


10.3.5 “无 关联 组 合 操作 


我 将 拥有 多 个 可 以 独立 执行 的 子 操作 的 所 有 操作 都 称 为 无 关联 组 合 操作 。 以 下 这 些 操作 都 属于 这 
种 类 型 :AND-EOUAL .BITMAP AND 、BITMAP OR .BITMAP MINUS、CONCATENATION 、CONNECT BY WITHOUT FILTERING、 
HASH JOIN 、INTERSECTION 、MERGE JOIN .MINUS .MULTI-TABLE INSERT 、 SQL MODEL \ TEMP TABLE TRANSFORMATION 
以 及 UNION-ALL。 控 制 无 关联 操作 的 规则 除了 10.3.1 节 中 描述 的 规则 之 外 ， 还 包括 以 下 两 条 规则 。 
口子 操作 顺序 执行 ， 从 拥有 最 小 ID 的 操作 开始 直到 拥有 最 大 ID 的 操作 。 在 开始 处 理 随后 的 子 操 
作 之 前 ， 必 须 完全 执行 当前 的 子 操作 。 
口 一 个 子 操作 至 多 执行 一 次 并 且 独 立 于 其 他 所 有 的 子 操作 。 


注意 ”也 有 特别 的 情况 ， 就 是 MERGE JOIN 操作 的 子 操作 并 非 严 格 按照 刚刚 提 到 的 两 个 规则 执行 。14.3 
节 会 提供 相关 特殊 情况 的 具体 信息 。 
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下 面 是 基于 unrelated-combine.sql 脚 本 生成 输出 的 样 例 查 询 及 其 执行 计划 ( 其 父 - 子 关系 见 图 
10-4 ): 


SELECT ename FROM emp 
UNION ALL 

SELECT dname FROM dept 
UNION ALL 

SELECT '%' FROM dual 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1 | 19 | 
| 1 | UNION-ALL | 1 | 19 | 
| 2 | TABLE ACCESS FULL| EMP | 1 | 14 | 
| 3| TABLE ACCESS FULL| DEPT | 1 | 4 | 
| 4 | FAST DUAL | | 1 | 1 | 


图 10-4 ”UNION-ALL 无 关联 组 合 操作 的 父 - 子 关系 


在 这 个 执行 计划 中 , 无 关联 组 合 操作 是 UNION-ALL。 其 他 三 个 是 独立 操作 。 通 过 应 用 之 前 给 出 的 规 
则 ， 你 会 发 现 执行 计划 执行 的 操作 如 下 所 示 。 

(1) 操作 0 有 一 个 子 操作 (1)。 它 不 可 能 是 第 一 个 被 执行 的 操作 。 

(2) 操作 1 有 三 个 子 操作 ， 其 中 操作 2 是 按 升序 排列 的 第 一 个 。 因 此 ， 执 行 从 操作 2 开始 。 

(3) 操作 2 扫描 emp 表 并 将 14 行 数据 返回 给 它 的 父 操作 (1)。 

(4) 完全 执行 操作 2 之 后 ， 操 作 3 开 始 执行 。 

(5) 操作 3 扫描 dept 表 并 将 4 行 数据 返回 给 它 的 父 操作 (1)。 

(6) 完全 执行 操作 3 之 后 ， 操 作 4 开 始 执 行 。 

(7) 操作 4 扫描 dual 表 并 将 一 条 数据 返回 给 它 的 父 操作 (1)。 

(8) 操作 1 基于 它 从 子 操作 接收 到 的 所 有 数据 构建 一 个 单独 的 19 行 数据 的 结果 集 ， 并 将 它们 返回 给 
父 操作 (0)。 

(9) 操作 0 将 数据 发 送 给 调用 者 。 

注意 Starts 列 是 如 何 清晰 地 展示 每 个 操作 只 执行 了 一 次 的 。 

在 表 10-1 中 我 提 到 过 存在 Starts 列 含义 不 同 的 情况 。 有 时 候 这 个 列 提供 的 是 一 个 特定 的 内 存 结构 
被 访问 的 次 数 ， 而 不 是 执行 的 次 数 。 正 如 下 例 演示 的 那样 ，MERGE JOIN 操 作 可 以 用 来 展示 这 样 的 一 个 
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案例 。 注 意 对 于 操作 4， 其 Starts 列 的 值 为 4。 无 论 如 何 ， 也 没有 理由 将 数据 排序 四 次 。 但 其 实 此 内 存 
结构 被 访问 了 四 次 , 因此 才 有 了 4 这 个 值 出 现在 Starts 列 上 。 对 于 每 一 行 从 dept 表 抽取 出 来 的 数据 ,该 
内 存 结构 都 被 访问 了 一 次 ( 第 14 章 会 详细 解释 合并 联接 是 如 何 被 执行 的 ): 


Id Operation Name | Starts | E-Rows | A-Rows 
0 | SELECT STATEMENT | 年 省 14 
1 | MERGE JOIN | 1 | 14 14 
2 SORT JOIN | | 1 | 4 4 
3 | TABLE ACCESS FULL| DEPT | 1 | 4 4 
* 4 | SORT JOIN | 4 | 14 14 
5 TABLE ACCESS FULL| EMP | 1 | 14 14 


4 - access("E"."DEPTNO"="D"."DEPTNO") 
filter("E"."DEPTNO"="D"."DEPTNO") 


之 前 列 出 的 所 有 其 他 操作 都 与 本 节 展 示 的 UNION-ALL 操 作 拥有 相同 的 行为 。 简 而 言 之 , 无 关联 组 合 
操作 顺序 执行 它 的 每 个 子 操作 一 次 。 很 明显 ， 由 无 关联 组 合 操 作 自 己 执行 的 处 理 也 不 尽 相 同 。 
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我 将 拥有 多 个 子 操作 且 其 中 一 个 子 操作 控制 所 有 其 他 子 操作 的 执行 的 所 有 操作 称 为 关联 组 合 操 
作 。 下列 操作 均 属 于 这 种 类 型 : NESTED LOOPS、FILTER、UPDATE、CONNECT BY WITH FILTERING、UNION ALL 
( RECURSIVE NITH) 以 及 BITMAP KEY ITERATION。 控 制 关 联 组 合 操作 运行 的 规则 除了 之 前 10.3.1 节 中 描述 
的 规则 之 外 ， 还 包括 以 下 规则 。 

口 拥有 最 小 ID 的 子 操作 控制 其 他 子 操作 的 执行 。 

口 子 操作 从 拥有 最 小 了 p 的 操作 开始 执行 直到 拥有 最 大 ID 的 操作 。 但 是 ,与 无 关联 组 合 操作 相反 ， 

它们 不 是 顺序 执行 的 ， 而 是 按 某 种 交错 的 方式 执行 。 

口 只 有 第 一 个 子 操作 至 多 执行 一 次 。 其 他 所 有 子 操作 可 能 会 执行 多 次 或 根本 不 执行 。 

即使 这 种 类 型 的 操作 共享 相同 的 特性 ， 而 它们 当中 的 每 一 个 ， 在 某 些 方面 ， 都 有 自己 的 行为 。 我 
们 来 看 一 下 它们 中 各 自 的 样 例 (除了 BITMAP KEY ITERATION， 这 会 在 第 14 章 中 提 及 )。 注 意 接 下 来 的 部 
分 提供 的 所 有 例子 都 是 related-combine.sql 脚 本 生成 输出 的 摘录 。 


1. NESTED LOOPS 操 作 

这 个 操作 用 于 联接 两 组 数据 。 因 此 ， 它 总 是 有 两 个 子 操作 ， 不 能 多 也 不 能 少 。 拥 有 最 小 ID 的 子 操 
作 被 称 为 外 循环 或 驱动 行 源 。 第 二 个 操作 被 称 为 内 循环 。 这 个 操作 的 特性 是 ,外 循环 每 返回 一 条 数据 ， 
内 循环 都 要 执行 一 次 (第 14 章 会 详细 解释 嵌 套 循环 联接 是 如 何 执行 的 )。 

下 面 的 查询 及 其 执行 计划 就 是 这 样 的 例子 ( 图 10-5 展 示 了 它 的 父 - 子 关系 的 图 形 表示 ): 

SELECT 流 

FROM emp，dept 

WHERE emp.deptno = dept.deptno 


AND emp.comm IS NULL 
AND dept.dname != 'SALES' 
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| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 加 8 | 
| 1 | NESTED LOOPS | | 4 | 8 | 
|* 2 | TABLE ACCESS FULL | EMP | 1 | 10 | 
|* 3 | TABLE ACCESS BY INDEX ROWID| DEPT | 10 | 8 

|* 4 | INDEX UNIQUE SCAN | DEPT_PK | 10 | 10 | 


2 - filter("EMP"."COMM" IS NULL) 
3 - filter("DEPT"."DNAME"<>'SALES') 
4 - access("EMP"."DEPTNO"="DEPT"."DEPTNO") 


图 10-5 ”NESTED LOOPS 操 作 的 父 - 子 关系 


在 此 执行 计划 中 ，NESTED LOOPS 操 作 的 两 个 子 操作 都 是 独立 操作 。 通 过 应 用 之 前 描述 的 规则 ， 你 
会 发 现 执 行 计划 按 以 下 顺序 执行 各 个 操作 。 

(1) 操作 0 有 一 个 子 操作 (1)。 它 不 可 能 是 第 一 个 执行 的 操作 。 

(2) 操作 1 有 两 个 子 操作 (2) 和 (3)， 其 中 操作 2 是 按 升 序 排列 的 第 一 个 。 因 此 ， 操 作 2 ( 外 循环 ) 是 第 
一 个 被 执行 的 操作 。 

(3) 操作 2 扫描 emp 表 ， 应 用 "EMP"."COMM" IS NULL 过 滤 谓 词 并 将 10 行 数据 传递 给 它 的 父 操作 (1)。 

(4) 对 于 操作 2 返回 的 每 一 条 数据 ，NESTED LO0PS 操 作 的 第 二 个 子 操作 ， 即 内 循环 ， 都 要 执行 一 次 。 
这 是 通过 对 比 操作 2 的 A-Rows 列 和 操作 3 、 操 作 4 的 Starts 列 确认 的 。 

(5) 内 循环 由 两 个 独立 的 操作 构成 。 根 据 应 用 于 这 种 类 型 的 操作 的 规则 ， 操 作 4 是 在 操作 3 之 前 被 
执行 的 。 

(6) 操作 4 通过 应 用 "EMP"."DEPTNO"= "DEPT"."DEPTNO" 访 问 谓词 来 扫描 dept_pk 索 引 。 这 样 做 ， 它 通 
过 10 次 执行 从 索引 上 抽取 10 个 rowid 并 传递 给 它 的 父 操作 (3)。 

(7) 操作 3 通过 这 10 个 从 操作 4 返回 的 rowid 访 问 dept 表 。 对 于 每 个 rowid， 都 读 取 一 行 数据 。 接 下 来 
它 应 用 "DEPT"."DNAME"<>'SALES' 过 滤 谓 词 。 这 个 过 滤器 导致 两 行 数据 被 排除 掉 。 它 将 剩余 的 8 条 数据 
传递 给 它 的 父 操作 (1)。 

(8) 操作 1 将 这 8 条 数据 传递 给 它 的 父 操作 (0)。 

(9) 操作 0 将 数据 发 送 给 调用 者 。 

2. FILTER 操 作 

这 个 操作 的 特性 是 支持 不 同 数量 的 子 操 作 。 如 果 它 拥有 一 个 单独 的 子 操作 ， 就 可 以 将 它 视 为 一 个 
独立 操作 。 如 果 它 拥有 两 个 或 更 多 的 子 操作 ， 则 其 功能 与 NESTED LO0PS 操 作 类 似 。 第 一 个 子 操作 驱动 
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其 他 子 操作 的 执行 。 
为 了 说 明 这 一 点 ， 我 们 来 看 下 面 的 查询 及 其 执行 计划 ( 图 10-6 展 示 了 其 父 - 子 关系 的 图 形 表示 ): 


SELECT * 
FROM emp 
WHERE NOT EXISTS (SELECT 0 
FROM dept 
WHERE dept.dname = “SALES” AND dept.deptno = emp.deptno) 
AND NOT EXISTS (SELECT 0 
FROM bonus 
WHERE bonus .ename = emp.ename) 


| Id | 0peration | Name Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 8 | 
|* 1 | FILTER | 1 | 8 | 
| 2| TABLE ACCESS FULL | EMP | 14 | 
|* 3 | TABLE ACCESS BY INDEX ROWID| DEPT | 3 | 1 | 
i | INDEX UNIQUE SCAN | DEPT_PK 3 | 3 | 
| 5 | 一 IABLE ACEESS FULL | BONUS 8 | 0 | 


1 - filter( NOT EXISTS (SELECT 0 FROM "DEPT"7"DEPT" WHERE "DEPT"."DEPTNO"=:B1 
AND "DEPT"."DNAME"="'SALES') AND NOT EXISTS (SELECT 0 FROM "BONUS" 
"BONUS”WHERE "BONUS"."ENAME"=:B2)) 


3 - filter("DEPT"."DNAME"='SALES') 
4 - access("DEPT"."DEPTNO"=:B1) 
5 - filter("BONUS"."ENAME"=:B1) 


图 10-6 FILTER 操 作 的 父 - 子 关系 


警告 dbms xplan 包 中 的 display_cursor 函 数 有 时 候 会 显示 错误 的 谓词 。 然 而 ， 问 题 并 不 在 于 程序 包 。 
实际 上 是 由 显示 错误 信息 的 v$sql plan 和 v$sql plan statistics all 视 图 引起 的 。 在 这 种 情况 
下 , EXPLAIN PLAN 为 上 面 显 示 的 计划 显示 正确 的 谓词 , 但 是 视图 为 操作 1 显示 了 一 个 错误 的 谓词 : 
1 - filter (( IS NULL AND IS NULL)) 
注意 ， 根 据 Oracle 的 说 法 ， 这 不 是 一 个 bug， 只 是 当前 实现 的 一 个 限制 。 


在 这 个 执行 计划 中 ，FILTER 操 作 的 三 个 子 操作 为 独立 操作 。 应 用 之 前 描述 的 规则 ， 你 可 以 发 现 执 
行 计划 按 以 方式 执行 各 个 操作 。 
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(1) 操作 0 有 一 个 子 操作 (1) 。 它 不 可 能 是 第 一 个 被 执行 的 操作 。 

(2) 操作 1 有 三 个 子 操作 (2、3 和 5 )， 操 作 2 是 它们 当中 按 升序 排列 的 第 一 个 。 因 此 ， 执 行 从 操作 2 
开始 。 

(3) 操作 2 扫描 emp 表 并 将 14 条 数据 返回 给 它 的 父 操作 (1) 。 

(4) 对 于 操作 2 返回 的 每 条 数据 ，FILTER 操 作 的 第 二 个 和 第 三 个 子 操作 都 应 该 执行 一 次 。 而 实际 上 ， 
某 种 缓存 被 实现 以 将 执行 减 至 最 少 , 这 是 通过 将 操作 2 的 A-Rows 列 与 操作 3、5 的 Starts 列 相对 比 得 知 的 。 
操作 3 被 执行 了 三 次 ， 为 emp 表 的 deptno 列 的 每 个 不 重复 值 执行 了 一 次 。 操 作 5 执 行 了 八 次 ， 为 emp 表 在 
应 用 完 由 操作 3 施加 的 过 滤器 之 后 的 ename 列 的 每 个 不 重复 值 执行 了 一 次 。 下 面 的 查询 表明 starts 列 的 
数值 和 不 重复 值 的 数量 相 匹 配 : 


SQL> SELECT deptno, dname, count(*) 
2 FROM emp NATURAL JOIN dept 
3 GROUP BY deptno, dname; 


DEPTNO DNAME COUNT(*) 
10 ACCOUNTING 3 
20 RESEARCH 5 
30 SALES 6 


(5) 根据 独立 操作 的 规则 ， 操 作 4 是 在 操作 3 之 前 执行 的 ， 通 过 应 用 "DEPT"."DEPTNO"=:B1 访 问 谓词 来 
扫描 dept_pk 索 引 。 绑 定 变量 ( B1 ) 用 来 传递 通过 子 查询 检查 的 值 。 通 过 在 三 次 执行 中 都 这 样 做 ， 操 作 
从 索引 中 提取 三 个 rowid 并 将 它们 传递 给 它 的 父 操作 (3) 。 

(6) 操作 3 通过 从 它 的 子 操作 (4) 传递 过 来 的 rowid 访 问 dept 表 并 应 用 "DEPT"."DNAME"='SALES' 过 滤 谓 
词 。 因 为 这 个 操作 只 是 用 来 应 用 一 个 限制 条 件 ， 它 不 向 父 操 作 (1) 返回 任何 数据 。 它 仅 通知 父 操作 条 件 
是 否 满足 。 无 论 如 何 ， 应 该 注意 到 只 找到 一 行 满足 过 滤 谓 词 的 数据 。 因 为 使 用 了 NOT EXISTS， 这 个 匹配 
的 行 被 丢弃 掉 了 。 

ee i "ENAME"=:B1 过 滤 谓 词 。 绑 定 变 量 ( B1 ) 用 来 传递 通过 子 查询 
检查 的 值 。 因 为 这 个 操作 只 用 于 应 用 一 个 限制 条 件 ， 它 不 向 其 父 操作 (1) 返回 任何 数据 。 但 是 要 注意 
ee ee EXISTS， 没 有 数据 被 丢弃 掉 。 

(8) 在 应 用 完 由 操作 3 和 操作 5 实现 的 过 滤 谓 词 后 ， 操 作 1 将 结果 数据 返回 给 它 的 父 操作 (0 )。 

(9) 操作 0 将 数据 发 送 给 调用 者 。 


3. UPDATE 操 作 

这 个 操作 是 执行 某 个 UPDATE 语 句 时 使 用 的 。 它 的 特性 是 支持 不 同 数量 的 子 操作 。 大 多 数 时 候 ， 它 
拥有 一 个 单独 的 子 操作 而 且 因此 被 认为 是 独立 操作 。 只 有 在 SET 子 句 中 使 用 子 查 询 时 ， 才 会 有 两 个 或 
更 多 的 子 操作 可 用 。 如 果 它 拥有 不 止 一 个 子 操作 ， 那 么 第 一 个 子 操作 驱动 其 他 子 操作 的 执行 。 

下 面 是 一 个 样 例 SQL 语 句 及 其 执行 计划 ( 图 10-7 展 现 了 它 的 父 - 子 关系 的 图 形 表示 ): 

UPDATE emp el 


SET sal = (SELECT avg(sal) FROM emp e2 WHERE e2.deptno = el.deptno)， 
Comm = (SELECT avg(comm) FROM emp e3) 
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0 | UPDATE STATEMENT | 
1 | UPDATE | EMP | 
2 | TABLE ACCESS FULL | EMP | 
3 | SORT AGGREGATE | 
4| TABLE ACCESS FULL| EMP | 
5 | SORT AGGREGATE | 
6 | TABLE ACCESS FULL| EMP | 


图 10-7 ” UPDATE 操作 的 父 - 子 关系 


- filter("E2"."DEPTNO"=:B1) 


pid UPDATE 关联 组 合 操作 的 全 部 三 个 子 操作 都 是 独立 操作 。 之 前 描述 的 规则 表明 
执行 计划 按 以 下 方式 执行 各 个 操作 。 

(1) 操作 0 有 一 个 子 操作 (1) 。 它 不 可 能 是 第 一 个 被 执行 的 操作 。 

(2) 操作 1 有 三 个 子 操作 (2、3 和 5 )， 且 操作 2 是 这 三 个 中 按 升序 排列 的 第 一 个 。 因 此 ， 执 行 从 操作 
2 开始 。 

(3) 操作 2 扫描 emp 表 并 向 它 的 父 操作 (1) 返回 14 行 数据 。 

(4) 第 二 个 和 第 三 个 子 操作 (3 和 5 ) 可 能 会 被 执行 多 次 ( 最 多 会 与 操作 2 返回 的 行 数 相等 )。 因 为 
这 些 操作 都 是 独立 的 ， 且 每 个 操作 都 有 一 个 子 操作 ， 它 们 的 执行 从 子 操作 (4 和 6 ) 开始 。 

(5) 对 于 由 操作 2 返回 的 deptno 列 中 的 每 个 不 重复 值 ， 操 作 4 扫 描 emp 表 并 应 用 "E2"."DEPTNO"=:B1 过 
滤 谓 词 。 通 过 在 三 次 执行 中 这 么 做 ,操作 提取 出 14 行 数据 并 将 它们 传递 给 它 的 父 操作 (3) 。 

(6) 操作 3 计算 从 操作 4 传递 给 它 的 数据 的 平均 工资 ， 并 将 结果 返回 给 它 的 父 操作 (1) 。 

(7) 操作 6 扫描 emp 表 ， 提 取 14 行 数据 ， 并 将 它们 传递 给 它 的 父 操作 (5) 。 注 意 这 个 子 查询 只 执行 了 
一 次 ， 因 为 它 并 不 与 主 查询 相互 关联 。 

(8) 操作 5 计算 从 操作 6 传递 给 它 的 数据 的 平均 佣金 ， 并 将 结果 返回 给 它 的 父 操作 (1) 。 

(9) 操作 1 使 用 它 的 子 操作 (3 和 5 ) 返回 的 值 来 更 新 由 操作 2 传递 过 来 的 每 一 行 数据 ， 并 向 它 的 父 操 
作 (0) 传 递 更 新 的 行 数 。 注 意 ， 即 使 UPDATE 语 名 修改 了 这 14 行 数据 ， 这 个 操作 的 A-Rows 列 仍 显示 为 0。 

(10) 操作 0 向 调用 者 发 送 被 修改 的 行 数 。 


4. CONNECT BY WITH FILTERING 操 作 

这 个 操作 是 用 来 处 理 层 次 查询 的 。 它 的 特征 是 有 两 个 子 操作 。 第 一 个 用 来 获取 层次 的 顶级 ， 第 二 
个 为 层次 中 的 每 一 个 级 别 都 执行 一 次 

下 面 是 一 个 样 例 查询 及 其 计划 ( 图 10-8 展 示 了 它 的 父 - 子 关系 的 图 形 表示 )。 注 意 ， 该 执行 计划 是 


302 第 10 章 ”执行 计划 


在 11.2 版 本 下 生成 的 〈 原因 在 之 前 解释 过 了 ): 


SELECT level, rpad('-',level-1,'-')||ename AS ename, prior ename AS manager 
FROM emp : 

START WITH mgr IS NULL 

CONNECT BY PRIOR empno = mgr 


| Id Operation | Name Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1 | 14 | 
|* 1 | CONNECT BY WITH FILTERING | 1 14 | 
| 过 朗 TABLE ACCESS FULL | EMP | 1 1 

上 各 NESTED LOOPS | 4 43 | 
| 4 CONNECT BY PUMP | 4 14 | 
| 下 TABLE ACCESS BY INDEX ROWID| EMP 14 13 | 
|* 6 INDEX RANGE SCAN | EMP MGR_I 14 | 13 | 


1 - access("MGR"=PRIOR "EMPNO") 

2 - filter("MGR" IS NULL) 

6 - access("connect$ by$ pump$ 002"."PRIOR empno"="MGR") 
filter("MGR" IS NOT NULL) 


警告 上面 的 查询 代表 了 v$sql plan 和 v$sql plan statistics all 视 图 给 出 错误 信息 的 另 一 种 情况 
在 本 例 中 ，EXPLAIN PLAN 显示 了 上 面 显示 的 正确 谓词 ， 错 误 显 示 的 谓词 是 与 操作 1 关联 的 那个 : 
1 - access ("MGR"=PRIOR NULL) 


此 外 ， 与 操作 6 关联 的 访问 谓词 在 11.1 及 之 前 的 版 本 中 都 是 错误 的 。 


图 10-8 ”CONNECT BY WITH FILTERING 操 作 的 父 - 子 关系 


在 这 个 执行 计划 中 ，CONNECT BY WITH FILTERING 操 作 的 第 一 个 子 操作 是 独立 操作 。 不 同 的 是 ， 第 
二 个 子 操作 本 身 是 一 个 关联 组 合 操作 。 在 这 种 情况 下 读 取 一 个 执行 计划 ， 你 只 需要 简单 地 沿 着 关系 树 
下 行 递 归 应 用 规则 。 

为 了 帮助 你 更 容易 地 理解 层次 查询 的 执行 计划 ， 可 以 查看 一 下 查询 返回 的 数据 : 


LEVEL ENAME MANAGER 
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1 KING 

2 -JONES KING 
3 --SCOTT JONES 
4 ---ADAMS SCOTT 
3 --FORD JONES 
4 ---SMITH FORD 
2 -BLAKE KING 
3 --ALLEN BLAKE 
3 --WARD BLAKE 
3 --MARTIN BLAKE 
3 --TURNER BLAKE 
3 --JAMES BLAKE 
2 -CLARK KING 
3 --MILLER CLARK 


应 用 早 前 描述 的 规则 ， 你 会 发 现 执行 计划 按 以 下 方式 执行 各 个 操作 。 

(1) 操作 0 有 一 个 子 操作 (1)。 它 不 可 能 是 第 一 个 被 执行 的 操作 。 

(2) 操作 1 有 两 个 子 操作 (2 和 3)， 而 且 按 升序 排列 时 操作 2 排 在 第 一 。 因 此 ， ey 

(3) 操作 2 扫描 emp 表 ， 应 用 "MGR" IS NULL 过 滤 谓 词 ， 然 后 将 层次 的 根 ( KING ) 返回 给 它 的 父 操作 (1)。 

(4) 操作 3 是 操作 1 的 第 二 个 子 操作 。 因 此 它 会 为 层次 中 的 每 一 个 级 别 都 执行 ， ede 
当然 , 之 前 讨论 的 关于 NESTED LO0PS 操 作 的 规则 适用 于 操作 3。 第 一 个 子 操作 (4) 被 执行 了 ， 对 于 它 返 回 
的 每 一 行 ,会 将 内 循环 ( 由 操作 5 和 6 操作 组 成 ) 都 执行 一 次 。 注 意 ,正如 预期 的 ,操作 4 的 A-Rows 列 与 
操作 5 和 6 的 Starts 列 之 间 是 匹配 的 。 

(5) 对 于 第 一 次 执行 ， 操 作 4 通 过 CONNECT BY PUMP 操作 获取 层级 的 根 。 在 本 例 中 ， 级 别 1 只 有 一 条 
数据 (KING )。 通 过 这 个 值 ， 操 作 6 通 过 应 用 "MGR"=PRIOR "EMPNO" 访 问 谓 词 ( 显示 为 "connect$ by$_ 
pump$ 002". "pRIOR empno"="MGR" ) 对 emp_mgr i 索引 做 扫描 ， 应 用 过 滤 谓 词 "MGR”IS NOT NULL， 提 取 
出 rowid， 然 后 将 它们 返回 给 它 的 父 操 作 (5)。 操 作 5 通 过 这 些 rowid 访 问 emp 表 ， 并 将 数据 返回 给 它 的 父 
操作 (3)。 

(6) 对 于 操作 4 的 第 二 次 执行 ， 做 的 每 件 事 都 与 第 一 次 执行 的 一 样 。 唯 一 的 不 同 是 来 自 级 别 2 的 数 
据 (JONES、BLAKE 以 及 CLARK ) 被 传递 给 操作 4 用 于 处 理 (一 个 接 一 个 ， 每 一 行 都 会 引发 操作 4 的 
启动 )。 

(7) 对 于 操作 4 的 第 三 次 执行 ， 做 的 每 件 事 都 与 第 一 次 执行 的 一 样 。 唯 一 的 不 同 是 来 自 级 别 3 的 数 
据 (SCOTT、FORD、ALLEN、WARD、MARTIN、TURNER、JAMES 以 及 MILLER ) 被 传递 给 操作 4 
用 于 处 理 。 

(8) 对 于 操作 4 的 第 四 次 和 最 后 一 次 执行 ， 做 的 每 件 事 都 与 第 一 次 执行 的 一 样 。 唯 一 的 不 同 是 来 自 
级 别 4 的 数据 ( ADAMS 和 SMITH ) 被 传递 给 操作 4 用 于 处 理 。 

(9) 操作 3 获取 从 它 的 子 操作 传递 过 来 的 数据 ， 然 后 将 它们 返回 给 它 的 父 操作 (1)。 

(10) 操作 1 应 用 "MGR"” IS NOT NULL 过 滤 谓 词 。 

(11) 操作 0 将 数据 发 送 给 调用 者 。 

在 10.2.0.3 及 之 前 的 版 本 中 ， 生 成 的 执行 计划 有 着 细微 的 不 同 。 如 下 例 所 示 ，CONNECT BY WITH 
FILTERING 操 作 有 第 三 个 子 操作 (操作 8 )。 然 而 ， 在 本 例 中 ， 并 没有 执行 它 。 操 作 8 的 Starts 列 中 的 值 
证 实 了 这 一 点 。 实 际 上 ， 仅 当 CONNECT BY WITH FILTERING 操 作 使 用 临时 表 空 间 时 ， 才 会 执行 第 三 个 子 
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操作 。 到 那 时 候 性 能 铠 怕 会 严重 下 降 。 在 10.2.0.4 及 之 后 的 版 本 中 已 修复 这 个 问题 , 这 个 问题 被 称 为 bug 
5065418: 


| Id | Operation | Name | Starts | A-Rows 
|* 1 | CONNECT BY WITH FILTERING | | | 14 | 
| 二 各 TABLE ACCESS FUEL | EMP | :| 1 
| 3 | NESTED LOOPS | | 4 | 13 
| 4| BUFFER SORT | | 4 | 14 
| 5| CONNECT BY PUMP | | 4 | 14 
| 6 | TABLE ACCESS BY INDEX ROWID| EMP | 14 | 13 
|* 7 | INDEX RANGE SCAN | EMP_MGR_I | 14 | 13 
| 8 | TABLE ACCESS FULL | EMP | 0 | 0 


5. UNION ALL (RECURSIVE WITH) 操 作 
UNION ALL (RECURSIVE WITH) 操 作 从 11.2 版 本 开始 可 用 。 添 加 它 是 为 了 实现 递归 子 查询 因子 子 句 。 
因此 ， 会 将 它 用 于 层次 查询 。 注 意 实际 上 存在 着 两 个 有 关 的 操作 


UNION ALL (RECURSIVE WITH)BREADTH FIRST 
UNION ALL (RECURSIVE WITH)DEPTH FIRST 


顾名思义 ， 区 别 源 自 于 你 可 以 将 搜索 子 句 指定 为 BREADTH FIRST BY 或 者 DEPTH FIRST BY。 
下 面 是 一 个 样 例 查询 及 其 执行 计划 : 


WITH 

e (xlevel, empno, ename, job, mgr, hiredate, sal, comm, deptno) 

As ( | 
SELECT 1, empno, ename, job, mgr, hiredate;, sal, comm, deptno 
FROM emp 
WHERE mgr IS NULL 
UNION ALL 
SELECT mgr.xlevel+1, emp.empno, emp.ename, emp.job, emp.mgr, emp.hiredate, emp.sal, 
FROM emp，e mgr 
WHERE emp.mgr = mgr.empno 


SELECT +* 

FROM e 

| Id | 0peration | Name | Starts | A-Rows 

| 0 | SELECT STATEMENT | | 三 14 | 
| 411] VIEW | | 7 | 
| 2| UNION ALL (RECURSIVE WITH)BREADTH FIRST | | 1 | 14 | 
1 | TABLE ACCESS FULL | EMP | 了 二 | 
|， 琵 赴 NESTED LOOPS | | 4 | 13 | 
| NESTED LOOPS | | 4 | 43 1 
| 到 | RECURSIVE WITH PUMP | | 4 | 14 | 
| INDEX RANGE SCAN | EMP MGR I | 14 | 13 | 
1 | TABLE ACCESS BY INDEX ROWID | EMP | 13 | 13 


3 - filter("MGR" IS NULL) 
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7 - access("EMP"."MGR"="MGR"."EMPNO") 
filter("EMPp". "MGR" IS NOT NULL) 


读 取 一 个 包含 UNION ALL (RECURSIVE WITH) 操 作 的 执行 计划 与 读 取 一 个 包含 CONNECT BY WITH 
FILTERING 操 作 的 执行 计划 没什么 两 样 。 事实 上 ,两 个 操作 的 用 途 基本 上 是 相同 的 。 只 是 要 注意 执行 计 
划 中 使 用 的 PUMP 操作 不 一 样 。 在 前 者 中 它 被 称 为 RECURSIVE WITH PUMP ， 在 后 者 中 它 被 称 为 CONNECT BY 
PUMP。 无 论 如 何 ， 这 种 差别 ， 对 于 读 取 执 行 计划 的 目的 来 说 ， 是 无 关 紧 要 的 。 


10.3.7 分 而 治之 


在 前 面 的 章节 中 ,你 了 解 了 如 何 读 取 由 三 种 类 型 的 操作 组 成 的 执行 计划 。 到 目前 为 止 你 看 到 的 执 
行 计划 都 十 分 简单 ( 较 短 )。 人 然而， 多 半 情 况 下 ， 你 需要 面 对 复 杂 ( 较 长 ) 的 执行 计划 。 这 不 是 因为 
大 部 分 的 SQL 语句 都 是 复杂 的 ， 而 是 因为 很 可 能 简单 的 SQL 语句 能 被 查询 优化 器 很 好 地 优化 ， 因 此 你 
永远 不 必 去 怀疑 简单 语句 的 性 能 。 

要 认识 到 读 取 长 的 执行 计划 与 读 取 短 的 执行 计划 没有 本 质 区 别 。 你 所 需要 做 的 仅 是 有 条 理 地 应 用 
在 之 前 章节 中 提供 的 规则 。 有 了 它们 , 就 无 所 谓 执行 计划 有 多 少 行 。 只 要 按 相同 的 方式 进行 就 可 以 了 。 

为 了 向 你 展示 如 何 处 理 行 数 稍 多 的 执行 计划 ,我 们 来 看 一 下 图 10-9 中 的 执行 计划 所 执行 的 操作 ( 图 
10-10 展 示 了 其 父 - 子 关系 的 图 形 表示 )。 我 有 意 不 提供 用 来 生成 它 的 SQL 语句 。 对 于 我 们 的 目的 而 言 ， 
你 不 需要 关心 SQL 语句 本 上身。 换 名 话说， 执行 计划 才 是 关键 。 


0 SELECT STATEMENT 


1 FILTER 

2 SORT GROUP BY 

3 FILTER 

4 HASH JOIN OUTER G 
5 NESTED LOOPS OUTER E 
6 NESTED LOOPS g | 
7 [TABLE ACCESS FULL A 

8 TABLE ACCESS BY INDEX ROWID 

9 INDEX UNIQUE SCAN | 
10 [TABLE ACCESS BY INDEX ROWID | 
11 INDEX UNIQUE SCAN 
12 TABLE ACCESS FULL 日 
13 SORT UNIQUE J 
14 UNION-ALL 
35 TABLE ACCESS FULL H 
16 TABLE ACCESS FULL ! 


图 10-9 一 个 执行 计划 按 块 进行 分 解 。 左 边 的 数字 用 于 识别 操作 。 右 边 的 字母 用 于 识别 抉 


306 第 10 章 ”执行 计划 


图 10-10 图 10-9 中 展示 的 执行 计划 的 父 - 子 关系 


首先 ， 有 必要 将 查询 计划 分 解 为 基础 的 块 ， 并 识别 执行 的 顺序 。 为 此 ， 你 需要 实施 以 下 步 又。 最 
开始 为 了 读 取 执行 计划 ， 你 必须 识别 组 成 它 的 组 合 操作 ( 包括 关联 的 和 无 关联 的 )。 也 就 是 说 ， 你 十 
要 识别 每 一 个 拥有 不 止 一 个 子 操作 的 操作 。 在 图 10-9 所 示 的 例子 中 ,组合 操 作 包 括 : 3、4、5、6 和 14 
然后 ， 对 于 每 个 组 合 操作 中 的 每 个 子 操作 ， 都 定义 一 个 块 。 因 为 在 图 10-9 中 有 五 个 组 合 操作 ， 而 且 它 
们 当中 的 每 一 个 都 有 两 个 子 操 作 ， 所 以 一 共有 十 个 块 。 例 如 ， 对 于 操作 3， 第 一 个 子 操作 包含 从 第 4 行 
到 第 12 行 ( 块 G )， 而 第 二 个 子 操作 包含 从 第 13 行 到 第 16 行 ( 块 J)。 注 意 在 图 10-9 中 ， 每 个 块 都 被 一 个 
方 框 分 隔 开 来 。 最 终 ， 你 需要 找 出 这 些 块 的 执行 顺序 。 为 了 观察 这 是 如 何 完成 的 ， 我 们 完成 图 10-9 中 
展示 的 执行 计划 ， 并 应 用 之 前 讨论 的 规则 。 

(1) 操作 0 是 一 个 独立 操作 ， 它 的 子 操作 (1) 在 它 之 前 执行 。 

(2) 操作 1 是 一 个 独立 操作 ， 它 的 子 操作 (2) 在 它 之 前 执行 。 

(3) 操作 2 是 一 个 独立 操作 ， 它 的 子 操作 (3) 在 它 之 前 执行 。 

(4) 操作 3 是 一 个 独立 操作 ， 它 的 子 操作 在 它 之 前 执行 。 因 为 第 一 个 子 块 (G ) 在 第 二 个 子 块 (J) 
之 前 执行 ， 我们 继续 看 第 一 个 子 块 的 第 一 个 操作 (4)。 

(5) 操作 4 是 一 个 无 关联 组 合 操 作 ， 它 的 子 操作 在 它 之 前 执行 。 因 为 第 一 个 子 块 (E ) 在 第 二 个 子 
块 (F ) 之 前 执行 ,我 们 继续 看 第 一 个 子 块 (E ) 的 第 一 个 操作 (5)。 

(6) 操作 5 是 一 个 关联 组 合 操作 ， 它 的 子 操作 在 它 之 前 执行 。 因 为 第 一 个 子 块 (C ) 在 第 二 个 子 块 
(D ) 之 前 执行 ， 我们 继续 看 第 一 个 子 块 (C ) 的 第 一 个 操作 (6)。 

(7) 操作 6 是 一 个 关联 组 合 操作 ， 它 的 子 操作 在 它 之 前 执行 。 因 为 第 一 个 子 块 ( A ) 在 第 二 个 子 块 
( B ) 之 前 执行 ， 我们 继续 看 第 一 个 子 块 (A ) 的 第 一 个 操作 (7)。 

(8) 操作 7 是 一 个 独立 操作 而 且 没 有 子 操作 。 这 意味 着 你 终于 找到 了 第 一 个 被 执行 的 操作 ( 因为 它 
在 块 A 中 )。 该 操作 扫描 一 张 表 ， 并 将 数据 返回 给 它 的 父 操 作 (6)。 

(9) 块 B 需 要 为 由 块 A 返 回 的 每 一 行 都 执行 一 遍 。 在 这 个 块 中 , 起初 操作 9 扫描 一 个 索引 ,然后 操作 
8 使 用 返回 的 rowid 访 问 一 张 表 ， 并 最 终 将 数据 返回 给 它 的 父 操 作 (6)。 
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(10) 操作 6 在 由 块 A 和 B 返 回 的 数据 之 间 执 行 联接 操作 ， 然 后 将 结果 返回 给 它 的 父 操作 (5) 。 

(11) 块 D 需 要 为 由 块 C 返 回 的 每 一 行 都 执行 一 遍 。 换 句 话 说， 对 于 由 操作 6 返回 给 其 父 操作 (5) 的 每 
一 行 , 它 都 被 执行 了 一 次 。 在 这 个 块 中 ,一 开始 是 操作 11 扫 描 一 个 索引 。 然后 , 操作 10 通 过 返回 的 rowid 
访问 一 张 表 ， 并 将 数据 返回 给 它 的 父 操作 (5) 。 

(12) 操作 5 在 由 块 C 和 D 返 回 的 数据 之 间 执 行 联接 操作 ,然后 将 结果 返回 给 它 的 父 操作 (4) 。 

(13) 操作 12 ( 块 F ) 仅 执 行 一 次 。 它 扫描 一 张 表 ， 然 后 将 结果 返回 给 它 的 父 操作 (4) 。 

(14) 操作 4 在 由 块 E 和 F 返 回 的 数据 之 间 执 行 联接 操作 ， 然 后 将 结果 返回 给 它 的 父 操作 (3) 。 

(15) 块 J 基 本 上 是 对 于 块 G 返 回 的 每 一 行 数 据 都 要 执行 一 次 。 换 句 话 说， 对 于 由 操作 4 返回 给 其 父 
操作 (3) 的 每 一 行 数据 ， 它 都 要 被 执行 一 次 。 在 这 个 块 中 ， 首 先 操 作 15 扫 描 一 张 表 ， 然 后 将 数据 返回 
给 它 的 父 操作 (14)。 接 下 来 ,操作 16 扫 描 一 张 表 ， 并 将 数据 返回 给 它 的 父 操 作 (14)。 做 完 这些 ， 操 作 14 
将 它 的 各 个 子 操作 返回 的 数据 放 到 一 起 ， 并 将 结果 返回 给 它 的 父 操 作 (13)。 最 后 ， 操 作 13 移 除 部 分 宛 
余 的 数据 。 注 意 ， 这 个 块 不 会 将 数据 返回 给 其 父 操作 。 实 际 上 ， 父 操作 是 一 个 FILTER 操 作 ， 而 且 第 二 
个 子 操作 仅 用 来 应 用 一 个 限制 条 件 。 

(16) 一 旦 操作 3 在 块 J 上 应 用 了 过 滤 条 件 ， 就 将 结果 返回 给 它 的 父 操作 (2)。 

(17) 操作 2 执行 一 个 GROUP BY 操作 并 将 结果 返回 给 它 的 父 操作 (1)。 

(18) 操作 1 应 用 一 个 过 滤 条 件 然后 将 结果 返回 给 调用 者 。 

概括 起 来 ， 注 意 各 个 块 是 按照 它们 的 标识 符 顺序 执行 的 ( 从 A 一 直到 J] ), 一 些 块 (A、C、E、F 
以 及 G ) 至 多 执行 一 次 ， 而 其 他 的 块 (B、D、H、 I 以 及 J) 则 可 能 执行 多 次 (或 根本 不 执行 )， 这 要 取 
决 于 驱动 它们 的 操作 返回 了 多 少 条 数据 。 


10.3.8 ”特殊 情况 


前 面 章节 中 描述 的 规则 适用 于 绝 大 部 分 的 执行 计划 。 虽 然 如 此 , 还 是 有 一 些 特殊 情况 。 通 常 可 以 
通过 观察 操作 获知 执行 计划 做 了 哪些 事情 ， 它 们 应 用 的 谓词 ， 它 们 是 在 哪些 表 上 执行 的 以 及 它们 的 运 
行 时 行为 ( 尤其 是 Starts 和 A-Rows 列 ), 接 下 来 的 小 节 介 绍 了 从 众多 可 能 的 情况 中 挑选 出 来 的 三 个 例子 。 
注意 以 下 例子 都 是 对 special cases.sql 脚 本 生成 输出 的 摘录 。 


1. SELECT 子 句 中 的 子 查询 

这 个 例子 展示 了 在 SELECT 子 句 中 包含 一 个 子 查 询 的 查询 语句 的 执行 计划 是 什么 样子 的 。 查 询 及 其 
执行 计划 如 下 所 示 : 

SELECT ename, (SELECT dname 


FROM dept 
WHERE dept.deptno = emp.deptno) 


FROM emp 

| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 于 | 14 | 
| 1 | TABLE ACCESS BY INDEX ROWID| DEPT | 3 | 3 | 
|* 2 | INDEX UNIQUE SCAN | DEPT PK | 3 | 3 | 
| 3 | TABLE ACCESS FULL | EMP | 1 | 14 | 
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2 - access("DEPT"."DEPTNO"=:B1) 

奇怪 的 是 , 在 这 个 执行 计划 中 操作 0 有 多 个 子 操作 。 如 果 仔 细 观 察 starts 列 ， 就 会 注意 到 尽管 操作 
1 和 操作 2 被 执行 了 三 次 ， 操 作 3 仅 被 执行 了 一 次 。 还 要 注意 操作 1 和 操作 2， 因 为 它们 引用 了 dept 表 实 
现 了 子 查 询 。 这 个 不 寻常 的 执行 计划 按 以 下 步 又 执行 各 个 操作 。 

(1) 操作 3， 也 就 是 第 一 个 被 执行 的 操作 ， 扫 描 emp 表 并 将 所 有 的 数据 返回 给 它 的 父 操作 ( 0 )。 

(2) 对 于 操作 3 返回 的 每 一 行 数 据 ， 子 查询 都 应 该 被 执行 一 次 。 然 而 ， 在 本 例 中 SQL 引擎 也 缓存 了 
结果 ， 因 此 子 查询 只 是 为 deptno 列 中 的 每 个 不 重复 值 都 执行 了 一 次 。 

(3) 为 执行 子 查询 ， 操 作 2 通过 应 用 "DEPT"."DEPTNO"=:B1 访 问 谓词 来 扫描 dept_pk 索 引 ， 提 取 rowid， 
并 将 它们 返回 给 它 的 父 操作 (1) 。 绑 定 变 量 (8B1 ) 用 来 将 需要 检索 的 值 传递 给 子 查 询 。 然 后 操作 1 使 用 
这 些 rowid 访 问 dept 表 ， 并 将 数据 传递 给 它 的 父 操 作 (0 )。 

(4) 操作 0 将 数据 发 送 给 调用 者 。 


2. WHERE 子 句 中 的 子 查询 #1 

这 个 例子 展示 一 个 与 在 WHERE 子 句 中 包含 着 子 查 询 的 查询 语句 有 关 的 特殊 执行 计划 。 该 查询 及 其 
执行 计划 如 下 所 示 : 

SELECT deptno 


FROM dept 
WHERE deptno NOT IN (SELECT deptno FROM emp) 


| 0 | SELECT STATEMENT | | 二 a | 
|* 1| INDEX FULL SCAN -| DEPT PK | 1 | 1 | 
|* 2 | TABLE ACCESS FULL| EMP | 4 | | 


1 - filter( NOT EXISTS (SELECT 0 FROM "EMP" "EMP" WHERE 
LNNVL("DEPTNO"<>:B1))) 
2 - filter(LNNVL("DEPTNO"<>:B1)) 


警告 ”这 个 查询 是 v$sql plan 和 v$sql plan statistics al1 视 图 给 出 错误 信息 的 另 一 个 案例 。 在 本 例 
中 ，EXPLAIN PLAN 显示 如 上 所 示 的 正确 谓词 。 错 误 显示 的 谓词 是 与 操作 1 有 关 的 那个 : 
1- filter (IS NULL) 


乍 一 看 ， 这 个 执行 计划 是 由 两 个 独立 操作 组 成 的 。 如 果 仔 细 观 察 starts 列 ， 会 注意 到 某 些 地 方 有 
点 奇怪 。 事 实 上 ， 尽管 父 操作 (1) 只 被 执行 了 一 次 ， 但 子 操作 (2) 却 被 执行 了 四 次 。 实 际 上 ， 该 执行 计 
划 是 按照 以 下 步骤 执行 各 个 操作 的 。 

() 操作 1， 也 就 是 第 一 个 被 执行 的 操作 ,扫描 “dept_pk 索 引 。 对 于 deptno 列 中 的 每 个 值 ， 都 会 执行 
操作 2。 就 像 过 滤 谓 词 显 示 的 那样 ， 操 作 2 应 用 NOT EXISTS (SELECT 0 FROM "EMP" "EMP" WHERE LNNVL 
("DEPTNO"<>:B1)) 子 查询 。 注 意 , 查询 优化 器 将 NOT IN 转化 为 了 NOT EXISTS。 绑 定 变 量 ( B1 ) 用 来 向 子 
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查询 传递 需要 检索 的 值 。 

(2) 操作 2 扫描 emp 表 ， 应 用 LNNVL ("DEPTNO"<>:B1) 过 滤 谓 词 ， 并 将 数据 返回 给 它 的 父 操作 (1) 。 

(3) 对 于 满足 过 滤 谓 词 的 每 条 数据 ， 操 作 1 都 将 其 传递 给 它 的 父 操作 (0 )。 

(4) 操作 0 将 数据 发 送 给 调用 者 。 

对 于 同一 个 查询 语句 ， 查 询 优化 器 还 有 可 能 生成 下 面 的 执行 计划 。 但 是 ， 因 为 它 使 用 了 一 个 仅 从 
11.1 版 本 开始 可 用 的 特性 (NULL-aware anti-join )， 不 要 指望 在 10.2 版 本 中 看 见 这 种 类 型 的 执行 计划 。 
( 依 我 看 来 ， 这 个 执行 计划 远 比 上 一 个 更 容易 读 取 。 ) 


| Id | 0peration | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | .| 加 
|l* 1 | HASH JOIN ANTI NA | | 1 | 亚 | 
| 2| INDEX FULL SCAN | DEPT PK | 1 4 | 
| 3| TABLE ACCESS FULL| EMP | 1 | 14 | 


1 - access("DEPTNO"="DEPTNO") 


3. WHERE 子 句 中 的 子 查询 #2 

这 个 例子 是 上 一 个 的 扩展 。 它 也 涉及 在 MERE 子 名 中 的 子 查询 。 之 所 以 展示 它 ， 是 因为 想 提醒 大 
家 注意 这 样 的 事实 : 即使 实现 子 查询 的 编码 远 比 一 个 简单 的 查找 复杂 得 多 , 查询 优化 器 也 能 够 生成 类 
似 前 面 小 节 中 讨论 的 那 种 执行 计划 。 该 查询 及 其 执行 计划 如 下 : 

SELECT * 


FROM +t1 
WHERE n1 = 8 AND n2 IN (SELECT t2.n1 


FROM t2, t3 
WHERE t2.id = t3.id AND t3.n1 = 4); 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | :| 7 | 
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | «| 7 | 
|* 2 | INDEX RANGE SCAN | 项 | 1 | 7 | 
| HASH JOIN | | 13 | 设计 
| TABLE ACCESS FULL 13 | 13 | 1183 

|* 5| TABLE ACCESS FULL 1 了 | 13 | 910 | 


2 - access("N1"=8) 
filter( EXISTS (SELECT /*+ PUSH_SUBQ LEADING ("T3" "T2") FULL ("T3") 
USE_ HASH ("T2") FULL ("T2") */ 0 FROM "T3" "T3","T2" "T2" WHERE 
"T2"."ID"="T3"."ID" AND "T2"."N1"=:B1 AND "T3"."N1"=4)) 
3 ~ access("T2","ID"-"T3"."ID") 
4 - filter("T3"."N1"=4) 
5 - filter("T2"."N1"=:B1) 
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警告 ”这 个 查询 是 v$sql] plan 和 v$sql plan statistics all 视 图 给 出 错误 信息 的 另 一 个 案例 。 在 本 例 
中 ，EXPLAIN PLAN 显示 如 上 所 示 的 正确 谓词 。 错 误 显 示 的 谓词 是 与 操作 2 的 过 滤 条 件 相 关 的 那个 : 
2 - access ( "N1"=8) 
filter ( IS NOT NULL) 


同样 在 本 例 中 , 如果 仔细 观察 starts 列 , 会 注意 到 某 些 地 方 有 点 奇怪 。 直 到 2 操作 为 止 都 是 执行 了 
一 次 ， 而 从 3 到 5 的 操作 却 执 行 了 13 次 。 该 执行 计划 按 以 下 步 又 执行 各 个 操作 。 

(1) 操作 2， 也 就 是 第 一 个 被 执行 的 操作 ， 通 过 扫描 i1 索 引 来 应 用 "N1"=8 访 问 谓 词 。 它 从 索引 中 提 
取 的 ， 对 于 满足 访问 谓词 的 键 , 不 仅 是 rowid 而 且 还 有 n2 列 的 值 。 对 于 n2 列 中 的 每 个 不 重复 值 ， 子 查询 
( 操作 3 到 5 ) 都 被 执行 一 次 。 这 是 通过 应 用 过 滤 谓 词 来 完成 的 。 注 意 查 询 优化 器 将 IN 转换 成 了 EXISTS。 
子 查询 实施 的 联接 是 通过 一 个 散 列 联接 实现 的 ， 这 是 一 个 无 关联 组 合 操作 。 

(2) 操作 4， 散 列 联 接 的 第 一 个 子 操作 , 通过 全 表 扫 描 读 取 t3 表 并 将 满足 "T3"."N1"=4 过 滤 谓 词 的 数 
据 返回 给 它 的 父 操作 (3) 。 

(3) 操作 5， 散 列 联接 的 第 二 个 子 操作 ， 通 过 全 表 扫 描 读 取 t2 表 并 将 满足 "T2"."N1"=:B1 过 滤 谓 词 的 
数据 返回 给 它 的 父 操作 (3) 。 绑 定 变 量 ( B1 ) 用 来 向 子 查询 传递 需要 检索 的 值 。 

(4) 操作 3 联接 由 操作 4 和 5 传递 过 来 的 两 组 结果 集 。 当 至 少 有 一 行 数 据 被 找到 时 ， 它 将 数据 返回 给 
它 的 父 操 作 (2) 。 

(5) 对 于 每 条 满足 由 子 查询 实现 的 条 件 的 数据 ， 操 作 2 都 向 其 父 操 作 (]) 传递 一 个 rowid。 

(6) 操作 1 使 用 从 其 子 操作 (2) 接 收 的 rowid 来 访问 t14 表 并 提取 它 的 各 个 列 。 它 将 数据 传递 给 它 的 父 操 
作 (0)。 

(7) 操作 0 将 数据 发 送 给 调用 者 。 


10.3.9 自 适 应 执行 计划 


对 象 统计 信息 并 不 总 是 会 为 查询 优化 器 提供 用 于 找 出 最 优 执行 计划 所 需 的 全 部 信息 。 为 了 改进 这 
种 情况 ， 在 解析 阶段 ， 查 询 优化 器 可 以 利用 动态 采样 对 要 处 理 的 数据 获取 额外 的 洞察 力 。( 动态 采样 
在 第 9 章 中 描述 过 。 ) 此 外 ， 自 从 12.1 版 本 开始 ， 查 询 优化 器 能 够 将 某 些 决定 推迟 到 执行 阶段 。 其 思路 
是 ,利用 在 执行 计划 的 执行 部 分 可 以 收集 的 信息 来 决定 应 该 如 何 执行 其 他 部 分 。 基 于 这 个 目的 ,查询 
优化 器 引入 了 所 谓 的 子 计划 。 同 时 引入 的 还 有 负责 决定 应 该 激活 哪个 子 计划 的 操作 。 


注意 ” 自 适应 执行 计划 只 有 在 企业 版 中 才 可 用 。 


从 12.1 版 本 开始 ， 查 询 优化 器 能 在 以 下 状况 中 使 用 自 适应 执行 计划 。 

口 从 肉 套 循环 联接 切换 到 散 列 联接 ， 反 之 亦 然 。 

口 为 并 行 执行 的 SQL 语句 从 散 列 向 广播 切换 分 配方 法 。 

与 并 行 处 理 有 关 的 案例 会 在 第 15 章 中 介绍 。 下 面 的 例子 演示 切换 联接 方法 是 如 何 实现 的 。 这 是 一 
段 来 自 adaptive plan.sql 脚 本 生成 输出 的 摘录 。 此 查询 是 一 个 两 张 表 之 间 的 简单 联接 。 它 通过 普通 的 
嵌 套 循环 联接 执行 : 
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SOL> EXPLAIN PLAN FOR 
2 SELECT 学 
3 FROM t1, t2 
4 WHERE t1.id = t2.id 
5 AND tl1.n = 666; 


SQL> SELECT * FROM table(dbms xplan.display(format=>'basic +predicate +note')); 


PLAN_TABLE OUTPUT 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | 

| 1 | NESTED LOOPS | | 
| 2| NESTED LOOPS | | 
|* 3 | TABLE ACCESS FULL |T1 | 
|* 4 | INDEX UNIQUE SCAN | T2pPKk | 
| 5 | TABLE ACCESS BY INDEX RONID| T2 | 


3 - filter("T1"."N"=666) 
4 - access("T1"."ID"="T2"."ID") 


- this is an adaptive plan 


注意 , 上 面 摘 录 中 末尾 的 Note 部 分 指出 了 这 个 执行 计划 是 自 适应 的 然而 , 就 执行 计划 本 身 而 言 ， 
却 没有 任何 特别 的 地 方 。 而 事实 是 , 默认 情况 下 , dbms_xplan 包 的 display 函 数 只 显示 默认 的 执行 计划 。 
简单 来 说 ,这 是 查询 优化 器 在 不 考虑 自 适 应 执行 计划 时 会 选择 的 执行 计划 。 如 果 想 看 见 包含 子 计划 的 
完整 执行 计划 ， 必 须 在 使 用 dbms _xplan 包 时 指定 adaptive 修 饰 符 。 在 这 种 情况 下 ， 有 三 个 额外 的 操作 
会 在 该 执行 计划 中 显示 : 


SQL> SELECT * FROM table(dbms xplan.display(format=>' basic +predicate +note +adaptive')); 


PLAN_TABLE_OUTPUT 


| Id | Operation | Name | 
| SELECT STATEMENT | | 
| HASH JOIN | | 
| NESTED LOOPS | | 
| NESTED LOOPS | | 
| STATISTICS COLLECTOR | | 
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.| TABLE ACCESS FULL 3 
|* 6| INDEX UNIOUE SCAN | T2 PK | 
| 7 | TABLE ACCESS BY INDEX ROWID| T2 | 
|- 8| TABLE ACCESS FULL | 72 


1 - access("T1"."ID"="T2"."ID") 
5 - filter("T1"."N"=666) 
6 ~ access{ TI 了 = T2 TD ) 


- this is an adaptive plan (rows marked '-' are inactive) 
这 样 的 一 个 执行 计划 并 不 容易 读 取 ， 因 为 它 其 实 包 含 两 个 不 同 的 执行 计划 。 首 先 ， 是 基于 嵌 套 循 
环 联接 的 默认 执行 计划 : 


Id | Operation | Name 
0 | SELECT STATEMENT | 
1 | NESTED LOOPS | | 
2 | NESTED LOOPS | | 
| 3| TABLE ACCESS FULL | 1 
4 | INDEX UNIOUE SCAN | J 这. 
5 | TABLE ACCESS BY INDEX ROWID| T2 


| Id | Operation | Name | 


0 | SELECT STATEMENT | | 
1 | HASH JOIN | | 
2 | TABLE ACCESS FULL| T1 | 
3 | TABLE ACCESS FULL| T2 | 


基本 上 ， 当 t1 表 的 扫描 返回 少量 的 数据 时 ， 第 一 个 执行 计划 比 第 二 个 好 。 因 此 ， 要 决定 应 该 使 用 
哪个 执行 计划 ， 查 询 优化 器 会 估算 能 够 被 嵌 套 循环 联接 有 效 处 理 的 最 大 行 数 ( 称 作 转 折 点 )。 为 了 在 
执行 阶段 期 间 决 定 应 该 使 用 哪个 执行 计划 ，STATISTICS COLLECTOR 操 作 缓 存 并 记录 t1 表 的 扫描 返回 的 
记录 数 。 然 后 ， 只 有 当 记录 数 低 于 转折 点 的 数值 时 ， 骨 套 循环 联接 才 会 被 执行 。 否 则 ， 散 列 联接 会 被 
执行 。 此 时 的 执行 计划 通常 被 称 作 最 终 执行 计划 。 一 旦 最 终 执行 计划 确定 下 来 ， 就 会 禁用 STATISTICS 
COLLECTOR 操 作 ， 因 此 ， 不 会 发 生 进 一 步 的 缓存 。 此 外 ， 与 转折 点 方法 有 关 的 操作 也 会 禁用 。 


注意 ”要 知道 执行 计划 切换 只 会 发 生 在 子 游标 第 一 次 执行 时 。 所 有 后 续 执行 都 使 用 最 终 执 行 计划 。 


v$sql 动 态 性 能 视图 提供 一 个 新 的 列 帮 助 你 了 解 , 对 于 一 个 特定 的 子 游标 其 最 终 执行 计划 是 否 已 经 
选 定 。 这 个 列 就 是 is_resolved_adaptive_plan。 它 会 被 设置 为 以 下 值 。 
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口 NULL 意 味 着 与 该 游标 关联 的 执行 计划 不 是 自 适 应 的 。 

口 N 意 味 着 最 终 执 行 计 划 还 没有 被 确定 下 来 。 这 个 值 只 有 在 最 终 执行 计划 被 确定 下 来 之 前 才 可 以 
观察 到 。 

口 Y 意 味 着 最 终 执 行 计划 已 经 被 确定 下 来 。 

两 个 初始 化 参数 控制 自 适 应 执行 计划 。 

口 optimizer adaptive _ features 完全 启用 或 禁用 该 特性 。 将 这 个 参数 设置 为 FALSE 时 ， 会 禁用 自 
适应 执行 计划 。 默 认 值 是 TRUE。 

口 optimizer adaptive_ reporting_only 在 报告 模式 下 启用 或 禁用 自 适 应 执行 计划 。 这 个 模式 对 于 
评估 执行 计划 是 否 会 因为 自 适 应 执行 计划 而 改变 非常 有 用 。 当 设置 为 TRUE 时 ,就 会 生成 自 适 应 
执行 计划 ，SQL 引 擎 会 检查 转折 点 ,但 是 SQL 引擎 只 会 使 用 默认 的 执行 计划 。 然 后 , 通过 下 面 
ee 可 以 检查 如 果 完 全 启用 自 适应 执行 计划 ， 那 么 会 使 用 哪 一 个 执行 计 

， 上 默认 值 是 FALSE: 
SQL> ALTER SESSION SET optimizer adaptive reporting only = TRUE; 
SQL SELECT * 

2 FROM t1，t2 


3 WHERE t1.id = t2.id 
4 AND tl.n = 666; 


SQL> SELECT * 
2 FROM table(doms xplan.display cursor(format=>'basic +predicate +note +adaptive +report')); 


EXPLAINED SQL STATEMENT: 


SELECT * FROM t1, t2 WHERE t1,id = t2.id AND t1.n = 666 


Plan hash value: 1837274416 


0 | SELECT STATEMENT 


| | | 
|- * 1 | HASH JOIN | | 
| 2| NESTED LOOPS | | 
i NESTED LOOPS | | 
|- 4 STATISTICS COLLECTOR | | 
|* 5 TABLE ACCESS FULL IT1 | 
|* INDEX UNIQUE SCAN | T2 PK | 
| 7| TABLE ACCESS BY INDEX ROWID| T2 | 
|- 8 | TABLE ACCESS FULL |T | 


4 = 
5 -~ filter("T1"."N"=666) 
6 - access("T1"."ID"="T2". "ID") 


Note 
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- this is an adaptive plan (rows marked '-' are inactive) 


Adaptive plan: 


This cursor has an adaptive plan, but adaptive plans are enabled for 
reporting mode only. The plan that would be executed if adaptive plans 
were enabled is displayed below. 


Plan hash value: 1837274416 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
|* 1 | HASH JOIN | | 
|* 2 | TABLE ACCESS FULL| T1 | 
| 3 | TABLE ACCESS FULL| T2 | 


= MCS Td .TD TID") 
2 - filter("T1"."N"=666) 


- this is an adaptive plan 


为 了 控制 在 语句 级 别 是 否 用 了 自 适 应 计划 ， 自 12.1.0.2 起 可 使 用 hint (no_)adaptive_plan。 


10.4 识别 低 效 的 执行 计划 


遗憾 的 是 ， 要 确定 一 个 执行 计划 不 是 最 优化 的 ， 唯 一 的 办 法 是 找 出 男 一 个 更 好 的 。 虽 然 如 此 ， 笨 
单 的 检查 也 可 能 揭露 出 暗示 低 效 执行 计划 的 线索 。 接 下 来 会 介绍 两 种 我 用 于 此 用 途 的 检查 。 第 13 章 中 
介绍 了 男 一 种 用 于 评估 访问 路 径 效 率 的 检查 。 


10.4.1 错误 的 估算 


这 个 检查 背后 的 思路 很 简单 。 查 询 优化 器 计算 成 本 来 决定 哪些 访问 路 径 、 联 接 顺 序 以 及 联接 方法 
应 该 用 于 获取 一 个 高 效 的 执行 计划 。 如 果 成 本 的 计算 有 误 ， 则 很 可 能 查询 优化 融会 选择 一 个 非 最 优 的 
执行 计划 。 换 言 之 ， 错 误 的 估算 很 容易 导致 选择 错误 的 执行 计划 。 

直接 评价 一 个 SQL 语句 本 身 的 成 本 在 实践 中 是 不 可 行 的 。 检查 查 询 优化 器 执行 的 其 他 估算 则 相对 
容易 得 多 ， 这 种 方式 的 成 本 估算 基于 由 一 个 操作 返回 的 行 数 (基数 )。 检 查 估算 的 基数 十 分 容易 ， 因 
为 你 可 以 使 用 dbms xplan 包 的 display cursor 函数 ， 比 如 说 ， 可 以 直接 使 用 真实 的 基数 和 估算 的 作对 
比 。 就 像 你 刚刚 看 到 的 ， 只 有 当 两 个 基数 值 接近 时 才 表 明 查 询 优化 器 工作 良好 。 这 种 方法 的 一 个 核心 
特性 就 是 不 需要 SQL 语 句 或 数据 库 结 构 的 相关 信息 来 评价 执行 计划 的 优 劣 。 你 只 需 集中 精力 用 实际 的 
数据 对 比 估 算 的 信息 
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让 我 通过 一 个 例子 来 演示 一 下 这 个 概念 。 下 面 这 段 来 自 wrong_estimations.sql 脚 本 输出 的 摘录 展 
示 了 一 个 带 有 估算 ( E-Rows ) 和 实际 基数 ( A-Rows ) 的 执行 计划 。 正 如 你 所 看 到 的 ， 操 作 4 的 估算 是 完 
全 错误 的 (因此 还 有 操作 2 和 操作 3 )。 查询 优化 器 为 操作 4 估算 的 是 ， 只 返回 32 行 数据 而 不 是 80 016 行 。 
更 糟糕 的 是 ， 操 作 2 和 操作 3 是 关联 组 合 操作 。 这 意味 着 操作 6 和 操作 7， 实 际 上 被 分 别 执行 了 80 016 和 
75 808 次 ， 而 不 是 估算 的 只 执行 32 次 。 这 是 通过 Starts 列 的 值 确定 的 。 一 定 要 注意 操作 6 和 操作 7 的 估 
算是 正确 的 。 实 际 上 ， 在 作 比 较 之 前 ， 实 际 的 基数 ( A-Rows ) 必须 除 以 执行 的 数量 ( Starts ): 


SELECT count(t2.col2) 
FROM t1 JOIN t2 USING (id) 
WHERE t1.col1 = 666 


| Id | 0peration | Name | Starts | E-Rows | A-Rows 
0 | SELECT STATEMENT | | 轴 a 

1 | SORT AGGREGATE | | 1 | 1 1 

2 NESTED LOOPS | | 1 | 75808 

3 NESTED LOOPS | 列 | 32 75808 

4 TABLE ACCESS BY INDEX ROWID| T1 | | 32 80016 
要 INDEX RANGE SCAN 1 -TL COL | pi 32 80016 
才 后 INDEX UNIOUE SCAN | T2.PKk | 80016 | 1 75808 
7 TABLE ACCESS BY INDEX ROWID | T2 | 75808 | 1 | 75808 


5 - access("T1"."COL1"=666) 
6' = SEEESSL0 下 TD T2". ID") 


要 理解 这 个 问题 ， 必 须 仔细 分 析 为 何 查询 优化 器 无 法 计算 合理 的 估算 。 基 数 通过 将 选择 率 和 表 中 
的 行 数 相 乘 计算 得 来 。 因此， 如 果 基 数 是 错误 的 ， 引 发 问题 的 原因 只 能 有 三 个 : 错误 的 选择 率 、 错 误 
的 行 数 或 查询 优化 器 的 bug。 

在 本 例 中 ,我们 的 分 析 应 该 始 于 查看 为 操作 5 执行 的 估算 ， 也 就 是 与 "T1"."COL1"=666 谓 词 相关 的 
估算 。 因 为 查询 优化 器 基于 对 象 统计 信息 做 估算 ， 那 我 们 来 看 一 下 它们 是 否 代表 了 当前 的 数据 。 通 过 
下 面 的 查询 ， 能 够 获取 用 于 操作 5 的 t1_col1 索 引 的 对 象 统计 信息 。 同 时 ， 也 可 以 计算 每 个 键 的 平均 数 
据 行 数 。 这 基本 上 就 是 在 没有 直方 图 可 用 时 查询 优化 器 会 使 用 的 值 : 

SQL> SELECT num rows, distinct keys, num rows/distinct keys AS avg rows per key 


2 FROM User indexes 
3 WHERE index name = 'T1 COL1'; 


NUM ROWS DISTINCT KEYS AVG ROWS PER KEY 


160000 5000 驼 
在 本 例 中 需要 注意 的 是 , 平均 行 数 32 与 上 面 的 执行 计划 中 估算 的 值 一 样 。 要 检查 这 些 对象 统 计 信 
恩 是 否 正 确 ， 必 须 将 它们 与 实际 数据 进行 对 比 。 那 么 ， 我 们 在 t1 表 上 执行 下 面 的 查询 。 正 如 你 所 看 到 
的 ， 该 查询 不 仅 计算 上 一 个 查询 的 对 象 统计 信息 而 且 还 记录 col1 列 上 不 等 于 666 的 行 数 : 
SQL> SELECT count(*) AS num rows, count(DISTINCT col1) AS distinct keys, 


3 count (nullif(col1,666)) AS rows per key 666 
3 FROM t4; 
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NUM ROWS DISTINCT KEYS ROWS PER KEY 666 


160000 5000 79984 
从 输出 中 可 以 确认 ， 对 象 统计 信息 是 正确 的 ， 而 且 数 据 倾斜 也 很 严重 。 因 此 ， 直 方 图 对 于 正确 的 
估算 绝对 是 有 必要 的 。 通 过 下 面 的 查询 ， 可 以 确认 在 本 例 中 没有 直方 图 存在 : 


SQL> SELECT histogram, num buckets 
2 FROM user tab col statistics 
3 WHERE table name = 'T1' AND column name = 'COL1'; 


HISTOGRAM NUM BUCKETS 


效 的 : 


| Id | Operation | Name | Starts | E-Rows | A-Rows | 
| SELECT STATEMENT | | 1 | 
| SORT AGGREGATE | 


| 

| | 1 

| 80000 | 75808 | 
TABLE ACCESS FULL| T1 | 80000 | 80016 | 
TABLE ACCESS FULL| T2 | 151K| 151K| 


ol | 

1 | | 
|* 2 | HASH JOIN | 

3 | | 

4 | | 


2 - access("T1"."ID"="T2"."ID") 
3 - filter("T1"."COL1"=666) 


注意 ,在 12.1 版 本 不 禁用 自 适应 执行 计划 时 执行 wrong_estimations.sql 脚 本 时 ， 查 询 优 化 器 
生成 了 一 个 自 适应 执行 计划 , 结果, 在 运行 时 自动 发 现 , 对 于 这 个 查询 ， 散 列 联接 要 比 骨 套 循环 更 
合适 。 


10.4.2 ”未 识别 限制 条 件 


我 必须 警告 你 上 一 节 中 呈现 的 检查 要 优越 于 本 节 的 。 我 通常 只 在 执行 过 第 一 个 检查 之 后 才 使 用 本 
节 的 第 二 个 检查 。 这 个 检查 的 思路 是 验证 查询 优化 器 是 否 正 确 地 识别 出 SQL 语 句 的 限制 条 件 ， 从 而 尽 
可 能 早 地 应 用 它 。 换 言 之 ,检查 执行 计划 是 否 会 导致 不 必要 的 处 理 。 

让 我 通过 一 个 例子 来 演示 一 下 这 个 概念 ， 这 个 例子 基于 下 面 的 restriction_not _recognized.sql 
脚本 产生 输出 的 摘录 。 从 中 ， 可 以 看 到 查询 优化 器 决定 以 联接 t1 和 t2 表 开始 。 第 一 个 联接 返回 40 000 
行 的 结果 集 。 稍 后 ， 该 结果 集 与 t3 表 进行 联接 。 只 产生 了 100 行 的 结果 集 ， 尽 管 该 操作 读 取 了 ft3 表 返 
回 的 80 000 行 数据 。 这 就 意味 着 查询 优化 器 没有 识别 限制 条 件 ， 而 当 大 量 的 处 理 已 经 被 执行 后 再 应 用 
它 就 太 晚 了 。 顺 便 说 一 下 ， 估 算 联接 基数 ， 是 查询 优化 器 必须 执行 的 最 难 的 任务 之 一 : 

SELECT count(t1.pad)，count(t2.pad)，count(t3.pad) 


FROM t1, t2, t3 
WHERE t1.id = t2.t1 id AND t2.id = t3.t2 id 
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Id | Operation Name | Starts | E-Rows | A-Rows 
0 | SELECT STATEMENT 1 | 上 
1 | SORT AGGREGATE | 1 | 1 1 
米 昌 HASH JOIN | 1 | 79800 100 
* 3 HASH JOIN 1 | 40000 | 40000 
4 TABLE ACCESS: PYULLY Tt 1 | 20000 20000 
5 TABLE ACCESS FULL| T2 1 | 40000 | 40000 
6 TABLE ACCESS FULL | T3 | 1 | 80000 | 80000 


2 - :access("T2", "ID"="T3", "T2 1D") 
3 - access("T1"."ID"="T2";"T1 1D") 
遇 到 这 样 的 问题 时 ， 你 可 能 会 束手无策 。 事实 上 ,没有 用 来 描述 两 张 表 之 间 的 关系 的 对 象 统计 信 
息 。 修 正 这 种 问题 的 一 个 可 行 的 办 法 是 使 用 SQL 概 要 。 在 本 例 中 应 用 一 个 SQL 概 要 会 给 出 如 下 的 执行 
计划 。( 我 在 第 11 章 中 介绍 了 什么 是 SQL 概 要 以 及 它 是 如 何 工作 的 。) 目前 ,重要 的 是 要 意识 到 有 解决 
方案 存在 。 要 注意 ， 不 仅 是 联接 顺序 改变 了 ( t2 > t3 > tl )， 连 访问 t1 表 的 方式 也 不 同 了 : 


Id Operation Name” | Starts | E-Rows | A-Rows 
0 | SELECT STATEMENT | 1 | | 1 
1 | SORT AGGREGATE | LL | 1 
2 NESTED LOOPS | 1 | | 100 
3 NESTED LOOPS | 至 | 100 | 100 | 

WE HASH JOIN | /| 100 | 100 | 
5 TABLE ACCESS FULL T2 | 1 | 40000 | 40000 
6 | TABLE ACCESS FULL T3 | 1 | 80000 | 80000 

SS INDEX UNIQUE SCAN Ta Pk- | 100 | 切 | 100 
8 | TABLE ACCESS BY INDEX ROWID| T1 | 100 | 1 | 100 


4 - access("T2"."ID"="T3"."T2 ID") 
2 = eess(" Ta ID Ta Ta DD) 


10.5 小结 


本 章 描 述 了 如 何 通过 EXPLAIN PLAN 语句 、 动 态 性 能 视图 、AWR 、Statspack 以 及 一 些 跟踪 工具 来 获 
取 执 行 计划 。 正 如 对 前 四 种 技术 讨论 的 那样 ， 对 于 提取 和 格式 化 执行 计划 ，dbms_xplan 包 是 首选 的 工 
具 。 通 过 它 ， 你 能 够 轻松 获取 需要 的 所 有 信息 ， 从 而 能 够 理解 执行 计划 。 本 章 还 讨论 了 一 些 用 于 解释 
执行 计划 以 及 用 于 识别 它们 是 否 高 效 的 规则 。 

很 明显 ， 引 起 性 能 问题 的 低 效 执行 计划 应 该 被 优化 。 为 此 ， 第 四 部 分 开篇 通过 描述 可 用 的 SQL 优 
化 技术 来 介绍 这 个 主题 。 注 意 ， 有 多 种 技术 存在 着 ， 因 为 其 中 每 种 技术 都 可 以 应 用 于 特定 的 情况 或 只 
适用 于 特定 问题 的 优化 。 


本 


工程 的 目的 并 不 在 于 获得 完美 的 解决 方案 ， 而 在 于 使 用 有 限 的 资源 做 到 最 好 。 
。 一 一 兰 迪 波 许 ，The Last Lecture，2008 


只 有 确定 了 性 能 问题 的 主要 原因 ， 你 才 应 该 去 尝试 解决 。 无 论 遇 到 的 是 什么 问题 ， 必 须要 
达到 的 目的 是 减少 (或 者 更 好 的 情况 一 一 消除 ) 最 耗 时 操作 花费 的 时 间 。 请 注意 单独 一 个 操作 
可 以 由 多 个 动作 一 个 接 一 个 地 执行 。 例 如 ， 一 个 返回 多 行 数据 的 查询 操作 会 涉及 多 次 获取 数据 

第 11 章 将 介绍 可 用 的 SQL 优化 技巧 ， 并 讲解 如 何 选择 它们 。 第 12 章 将 介绍 解析 是 如 何 工 
作 的 ， 如 何 发 现 解析 的 问题 ， 以 及 如 何在 不 影响 性 能 的 情况 下 减 小 解析 的 影响 。 第 13 章 将 介绍 
如 何 利用 可 用 的 访问 结构 来 更 有 效率 地 获取 单独 一 张 表 里 的 数据 。 第 14 章 将 抛 开 单 表 ， 介 绍 如 
何 多 表 联 合 获取 数据 。 第 15 章 介 绍 并 行 处 理 和 加 速 流 插 入 的 技术 , 以 及 减少 组 件 间 交互 的 技术 。 
第 16 章 将 介绍 物理 存储 参数 是 如 何 显著 影响 性 能 的 。 简 单 地 说 ;， 这 部 分 章节 的 主要 目的 是 利用 
Oracle 数据 库 提供 的 众多 特性 来 缩短 操作 与 SQL 引擎 相互 影响 的 啊 应 时 间 。 


saQL 优 化 技巧 。/ 


每 当 查 询 优 化 器 无 法 自动 生成 有 效 的 执行 计划 时 ， 就 需要 手工 优化 了 。 表 11-1 总 结 了 Oracle 数 据 
库 为 此 提供 的 一 些 技 术 手段 。 本 章 目 标 不 仅 是 详细 介绍 这 些 技巧 ， 而 且 还 会 解释 每 个 技巧 的 作用 及 其 
适合 的 场景 。 你 需要 问 自己 下 面 三 个 基础 问题 来 决定 使 用 哪 种 技巧 。 

口 SQL 语句 是 否 为 已 知 的 和 静态 的 ? 

口 针对 单个 会 话 (或 者 整个 系统 )， 获 取 到 的 测量 值 会 影响 单条 SQL 语句 还 是 所 有 SQL 语句 ? 

口 SQL 语句 可 以 修改 吗 ? 


表 11-1 SQL 优化 技巧 及 其 影响 


技 巧 系 统 会 话 SQL 语句 可 用 版 本 

修改 访问 结构 Vv 所 有 版 本 

修改 SQL 语 句 Vv 所 有 版 本 

hint We 所 有 版 本 
修改 执行 环境 过 Vv 所 有 版 本 

存储 概要 Vv 所 有 版 本 

SQL 概要 Vv 所 有 版 本 

SQL 计 划 管 理 Vv 从 版 本 11.1 开 始 


* 你 必须 更 改 SQL 语句 才能 使 用 此 技巧 。 
+ 需要 Tuning Pack， 因 此 需要 使 用 Enterprise Edition。 
了 需要 Enterprise Edition。 


让 我 来 解释 下 这 三 个 问题 的 重要 性 。 首 先 ，SQL 语 名 有 时 无 法 简单 获取 到 ， 因 为 它们 是 在 运行 时 
生成 的 ， 并 几乎 在 每 次 执行 时 都 在 改变 。 其 他 情况 下 ， 查 询 优化 需 无 法 正确 处 理 许多 SQL 语句 使 用 的 
特殊 模式 〈 比如 WHERE 条 件 的 限制 而 不 能 使 用 索引 )。 在 这 些 情 况 下 ， 你 需要 利用 技巧 来 解决 会 话 或 系 
统 级 别 的 问题 ， 而 不 是 SQL 语句 级 别 。 但 这 会 带 来 两 个 问题 。 一 方面 ， 就 像 表 11-1 总 结 的 那样 一些 
技巧 只 能 用 在 特定 的 SQL 语句 上 。 它 们 无 法 在 会 话 或 系统 级 别 使 用 。 另 一 方面 ， 就 像 第 9 音 解 释 的 那 
样 ， 当 数据 库 设 计 良 好 并 且 查 询 优化 器 正确 配置 时 ， 通 常 只 需要 优化 一 小 部 分 SQL 语句 。 因 此 ， 需 要 
避免 技巧 影响 到 由 查询 优化 器 自动 提供 高 效 执行 计划 的 SQL 语句 。 其 次 ， 每 当 处 理 不 可 控 的 SQL 语句 
应 用 时 ( 要么 是 因为 代码 无 法 访问 ， 比 如 包 的 应 用 ， 要 么 就 是 SQL 语句 是 在 运行 时 生成 的 )， 你 都 无 
法 使 用 需要 更 改 代码 的 技巧 。 总 之 ,通常 你 的 选择 是 受 限 的 。 

本 章 的 主要 目的 并 非 介 绍 如 何 找 出 指定 SQL 语句 的 最 佳 执行 计划 ， 例 如 ， 介 绍 特定 访问 或 联 
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接 方法 应 使 用 的 场景 。 该 分 析 会 在 本 部 分 的 其 他 章节 介绍 。 本 章 的 唯一 目的 是 介绍 可 用 的 SQL 优 
化 技巧 。 

介绍 每 一 种 SQL 优化 技巧 的 编排 方式 都 是 相同 的 : 先是 简介 ， 然 后 解释 该 技巧 的 工作 原理 ， 告 诉 
你 应 该 在 何 时 使 用 它 ， 最 后 讨论 一 些 常 见 的 误区 和 雇 误 。 


11.1 修改 访问 结构 


该 技巧 不 是 某 一 特定 特性 。SQL 语 句 的 响应 时 间 不 仅 非 常 依赖 于 存储 数据 处 理 的 方式 ， 同 时 也 依 
赖 于 处 理 数据 的 访问 方式 。 


11.1.1 工作 原理 


怀疑 一 个 SQL 语句 有 性 能 问题 时 ， 首 先 要 做 的 是 确定 当前 使 用 的 访问 结构 。 基 于 在 数据 字典 里 找 
到 的 信息 ， 可 以 获得 以 下 反馈 。 

口 涉及 的 表 的 组 织 类 型 是 什么 ? 是 堆 表 、 索 引 组 织 表 还 是 外 部 表 ? 或 者 是 存储 在 群集 中 的 表 ? 

口 物化 视图 包含 的 数据 是 否 可 用 ? 

口 表 、 和 群集 和 物化 视图 上 存在 什么 索引 ? ;索引 都 包含 了 哪些 列 以 及 列 的 排列 顺序 如 何 ? 

口 这 些 段 是 如 何 分 区 的 ? 

接 下 来 需要 评 佑 可 用 的 访问 结构 是 否 能 够 高 效 处 理 你 要 优化 的 SQL 语句 。 例 如 ， 分 析 期 间 ， 你 可 
能 会 发 现 对 SQL 语句 的 MERE 条 件 增加 索引 可 以 提高 效率 。 假 设 你 在 研究 以 下 查询 的 性 能 : 

SELECT * 


FROM emp 
WHERE empno = 7788 


基本 上 ， 查询 优化 右 会 运行 下 面 的 执行 计划 。 第 一 个 执行 计划 执行 一 次 全 表 扫 描 ， 而 第 二 个 通过 
索引 访问 表 。 当 然 ， 第 二 个 只 有 在 索引 存在 时 才 会 生成 : 


0 | SELECT STATEMENT | | 
1 | TABLE ACCESS FULL| EMP | 


0 | SELECT STATEMENT | 
1 | TABLE ACCESS BY INDEX ROWID| EMP | 
2 | INDEX UNIQUE SCAN | EMP_PK | 


第 四 部 分 的 多 个 章节 会 详细 介绍 不 同 的 访问 结构 应 该 用 在 何 时 以 及 如 何 使 用 , 因此 这 里 不 做 过 多 
介绍 。 现 在 ， 重 要 的 是 ， 认 识 到 这 是 一 种 基本 SQL 优化 技巧 。 
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11.1.2 ” 何 时 使 用 


在 适当 的 位 置 没有 必要 的 访问 结构 ， 或 许 就 不 可 能 优化 SQL 语 句 。 因 此 ， 你 需要 在 任何 可 以 改变 
访问 结构 的 时 候 使 用 该 技巧 。 不 幸 的 是 ， 这 并 不 总 是 可 行 ， 比 如 当 你 处 理 封 装 的 应 用 并 且 供 应 商 不 支 
持 修改 访问 结构 的 时 候 。 


11.1.3 ”陷阱 和 诬 误 


修改 访问 结构 时 ， 必 须 谨慎 处 理 可 能 产生 的 影响 。 一 般 来 说 ， 每 次 修改 访问 结构 都 会 带 来 正面 与 
负面 的 影响 。 实 际 上 , 这 种 影响 不 太 可 能 只 局 限于 单条 SQL 诸 句 。 只 有 在 少数 情况 下 才 不 会 产生 影响 。 
例如 ， 在 前 面 类 似 例 子 中 要 增加 索引 ， 就 需要 考虑 索引 会 减 慢 索引 表 上 每 条 INSERT 和 DELETE 语 句 的 执 
行 速度 ， 同 样 修改 索引 列 的 每 条 UPDATE 语 句 也 会 产生 同样 的 结果 。 还 应 该 检查 是 否 有 足够 的 空间 来 增 
加 访问 结构 。 总 的 来 说 ， 在 修改 访问 结构 之 前 需要 仔细 判断 是 否 利 大 于 次 。 


11.2 :修改 SQL 语句 


SQL 是 一 种 非常 强大 并 且 灵 活 的 查询 语言 。 你 能 够 用 不 同 的 方法 频 党 地 提交 同样 的 请 求 。 这 点 对 
于 开发 人 员 来 说 特别 有 用 。 然 而 对 于 查询 优化 器 来 说 ， 为 各 种 各 样 的 SQL 语句 提供 高 效 的 执行 计划 才 
是 真正 的 挑战 。 请 记 住 ,灵活 是 性 能 的 敌人 。 


11.2.1 工作 原理 


举例 说 , 你 选择 了 scott 模 式 下 所 有 没有 员工 的 部 门 。 以 下 四 条 SQL 语句 返回 你 想 要 的 信息 。 这些 
语句 都 可 以 在 depts_wo_emps.sql 脚 本 中 找到 : 
SELECT deptno 


FROM dept 
WHERE deptno NOT IN (SELECT deptno FROM emp) 


SELECT deptno 
FROM dept 
WHERE NOT EXISTS (SELECT 1 FROM emp WHERE emp.deptno = dept.deptno) 


SELECT deptno FROM dept 
MINUS 
SELECT deptno FROM emp 


SELECT dept.deptno 
FROM dept，emp 
WHERE dept.deptno = emp.deptno(+) AND emp.deptno IS NULL 


这 四 条 SQL 语句 的 目的 是 相同 的 ， 返 回 的 结果 集 也 是 相同 的 。 因 此 ， 你 或 许 期 望 查 询 优化 带 为 所 
有 的 情况 提供 相同 的 执行 计划 。 然 后 这 是 不 可 能 的 ， 实 际 上 ， 只 有 第 二 条 和 第 四 条 语句 使 用 相同 的 执 
行 计划 。 其 他 两 个 完全 不 同 。 请 注意 这 些 执行 计划 是 在 12.1 版 本 中 生成 的 。 其 他 版 本 会 生成 不 同 的 执 
行 计划 : 
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0 | SELECT STATEMENT | | 
1 | HASH JOIN ANTI NA | 

2 | INDEX FULL SCAN | DEPT_PK | 
3 | TABLE ACCESS FULL| EMP | 


0 | SELECT STATEMENT 
1 | HASH JOIN ANTI 

| 2| INDEX FULL SCAN 
3 | 


号 
m 
卫 了 
全 了 
Ae 
天 


TABLE ACCESS FULL| EMP 
| Id | 0peration | Name | 


| SELECT STATEMENT | 
| MINUS | | 
| SORT UNIOUE NOSORT| | 
| INDEX FULL SCAN | DEPT_PK | 
| SORT UNIOUE | 
| TABLE ACCESS FULL| EMP | 


0 | SELECT STATEMENT | 
1 | HASH JOINANTI | 
2 | INDEX FULL SCAN | DEPT PK | 
3 | TABLE ACCESS FULL| EMP | 


基本 上 ， 即 使 用 来 访问 数据 的 方法 总 是 相同 ， 用 来 合并 数据 产生 结果 集 的 方法 却 不 同 。 在 这 个 特 
殊 案例 里 ， 两 张 表 都 非常 小 ， 因 此 你 不 会 真正 注意 到 这 些 执行 计划 的 性 能 有 哪些 不 同 。 自 然 ， 如 果 你 
处 理 更 大 的 表 ， 就 不 会 是 这 样 了 。 通 常 来 说 ,在 你 处 理 大 量 数 据 时 ,执行 计划 里 每 个 细小 的 不 同 都 可 
在 响应 时 间 和 资源 利用 率 上 带 来 本 质 的 不 同 。 

这 里 的 关键 点 是 要 明白 同样 的 数据 可 以 由 不 同 的 SQL 语 句 提取 。 要 优化 一 条 SQL 语 句 ， 应 该 
先 考虑 是 否 存 在 其 他 等 价 SQL 语 句 。 如 果 存在 ,请 仔细 对 比 它们 的 执行 计划 ， 找 出 提供 最 佳 性 能 
的 那个 。 


11.2.2” 何 时 使 用 
只 要 能 够 更 改 SQL 语 句 ， 都 应 该 考虑 使 用 该 技巧 。 
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11.2.3 ”陷阱 和 请 误 


SQL 语句 是 代码 。 编 写 代 码 的 第 一 条 原则 就 是 可 维护 性 。 首 先 ， 这 代表 代码 应 该 可 读 性 高 并 且 简 
明 。 不 幸 的 是 ， 就 像 前 面 解释 的 那样 ， 最 简单 或 者 最 可 读 的 SQL 编写 方法 并 不 总 是 带 来 高 效 的 执行 计 
划 。 因 此 ， 某 些 情况 下 ,为 了 性 能 你 或 许 会 被 迫 放弃 可 读 性 与 简洁 性 ， 然 而 ， 仅 当 这 样 做 真正 必要 且 
有 益 时 才 会 这 样 做 。 


TB. hint 


根据 Merriam-Webster 在 线 字典 ，hint 是 一 个 间接 或 概要 的 建议 。 在 Oracle 的 术语 中 ，hint 的 定义 稍 
有 不 同 。 简 单 地 说 ，hint 是 添加 到 SQL 语 句 中 的 指令 ， 用 来 影响 查询 优化 器 的 判定 。 换 句 话说 ，hint 不 
是 仅仅 建议 某 个 动作 ， 而 是 向 着 该 动作 推进 。 在 我 看 来 ，Oracle 选 择 这 个 词 来 命名 此 功能 并 不 是 最 佳 
选择 。 无 论 如 何 ， 名 称 并 不 重要 ，hint 能 为 你 做 的 才 是 重要 的 。 不 要 让 名 称 误导 你 。 


警告 仅 因为 hint 是 一 个 指令 ， 并 不 代表 查询 优化 器 就 总 是 会 使 用 它 。 或 者 反 过 来 说 ,， 仅 因为 查询 优 
化 器 不 使 用 hint， 并 不 代表 hint 仅 仅 是 一 个 建议 。 就 像 我 稍 后 将 介绍 的 ， 有 些 案 例 里 ，hint 只 是 
不 相关 或 不 合法 ， 因 此 不 会 影响 查询 优化 器 生成 的 执行 计划 。 


11.3.1 工作 原理 


接 下 来 的 部 分 介绍 hint 是 什么 ，hint 的 分 类 及 如 何 使 用 它们 。 在 讨论 细节 之 前 需要 注意 ， 使 用 hint 
要 比 你 想象 得 重要 。 实 际 上 ， 在 实践 中 ，hint 被 错误 使 用 是 很 常见 的 。 


1. 什么 是 hint 

当 处 理 一 条 SQL 语句 时 ， 查 询 优化 器 会 考虑 许多 种 执行 计划 。 理 论 上 ， 它 会 考虑 所 有 可 行 的 执行 
计划 。 实 际 上 ， 除 了 简单 的 SQL 语句 之 外 ， 优 化 需 为 了 保持 合理 的 优化 时 间 ， 不 会 考虑 太 多 种 组 合 。 
因此 , 查询 优化 器 会 根据 推断 排除 某 些 执行 计划 。 当 然 ， 完 全 忽略 一 些 执行 计划 的 决定 很 关键 ,并且 
这 么 做 查询 优化 器 的 可 信和 性 也 会 受到 怀疑 。 

指定 一 个 hint 时 ， 你 的 目的 要 么 是 改变 执行 环境 ， 启 用 或 者 禁用 某 个 特性 ， 要 么 是 降低 查询 优化 
右 需 要 考虑 的 执行 计划 数量 。 除 非 改 变 执行 环境 ， 使 用 hint 你 将 告诉 查询 优化 器 ， 针 对 某 条 特定 SQL 
语句 应 该 考虑 哪些 操作 或 不 应 该 考虑 哪些 操作 。 例 如 ， 查 询 优 化 器 要 为 以 下 查询 生成 执行 计划 : 

SELECT * 

FROM emp 

WHERE empno = 7788 

如 果 emp 表 是 堆 表 并 且 empno 列 有 索引 ， 那 么 查询 优化 器 至 少 考虑 两 种 执行 计划 。 第 一 种 通过 全 表 
扫描 彻底 读 了 一 遍 emp 表 : 
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| 0 | SELECT STATEMENT | | 
| 1| TABLE ACCESS FULL| EMP | 


第 二 种 是 基于 WHERE 子 句 ( empno=7788 ) 的 谓词 做 一 次 索引 查找 ， 然 后 通过 在 索引 里 找到 的 rowid 
去 访问 表 中 的 数据 : 


| 0 | SELECT STATEMENT | 
| 1| TABLE ACCESS BY INDEX ROWID| EMP | 
| 2| INDEX UNIOUE SCAN | EMP_PK | 


在 这 样 的 案例 里 ， 要 控制 查询 优化 器 提供 的 执行 计划 ， 你 可 以 加 入 hint 来 指定 使 用 全 表 扫 描 或 者 
索引 扫描 。 重 要 的 是 需要 明白 你 不 能 告诉 查询 优化 器 ,， “我 想 要 在 emo 表 上 执行 全 表 扫 描 ， 所 以 去 搜 一 
个 包含 它 的 执行 计划 ”。 然 而 ， 你 可 以 告诉 它 ,“ 如 果 需 要 在 对 emp 表 执行 全 表 扫 描 还 是 索引 扫描 之 间 
做 出 选择 ,请 选择 全 表 扫 描 "。 这 是 一 个 轻 量 的 但 本 质 上 的 不 同 。 当 查询 优化 器 必须 在 几 个 可 能 的 执 
行 计划 间 选 择 时 ，hint 可 以 允许 你 影响 它 的 选择 。 

为 了 进一步 强调 这 点 ， 让 我 们 来 看 一 个 基于 图 11-1 显 示 的 决策 树 的 例子 。 请 注意 ， 即 使 查询 优化 
器 利用 决策 树 ， 这 也 只 是 个 一 般 的 例子 ， 并 没有 与 Oracle 数 据 库 有 直接 关系 。 在 图 11-1 中 ， 目 的 是 从 
决策 树 的 根 节点 (1) 向 下 终止 于 叶子 节点 ( 111~123 )。 换 句 话 说， 目的 是 从 点 A 到 点 B 选 择 一 条 路 径 。 
由 于 某 些 原因 ， 这 必定 会 经 过 节点 122 的 。 要 这 么 做 ， 在 Oracle 的 语法 里 就 需要 两 个 hint， 加 入 来 修剪 
从 节点 12 到 节点 121 和 节点 123 的 路 径 。 从 节点 12 到 节点 122 只 会 存在 这 唯一 的 一 条 路 径 。 但 这 并 不 足 
以 保证 路 径 经 过 节点 122。 实 际 上 ， 如 果 节 点 1 经 过 节点 11 而 不 是 节点 12， 那 么 这 两 个 hint 就 不 会 起 作 
用 。 因 此 ， 要 引导 路 径 通过 节点 122， 你 需要 增加 另外 一 个 hint 来 修剪 从 节点 1 到 节点 11 的 路 径 。 


A 
0 


8 
二 


图 11-1 修剪 决策 树 
查询 优化 器 也 会 发 生 类 似 的 情况 。 实 际 上 ， 只 有 在 查询 优化 器 决定 了 应 用 hint 的 选择 后 才 会 对 它 
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做 评估 。 因 此 ， 一 旦 指定 了 一 个 hint， 你 或 许 会 被 迫 加 入 儿 个 hint 来 确保 它 正常 工作 。 并 且 在 实践 中 ， 
随 着 执行 计划 复杂 度 的 增加 ， 想 要 找到 所 有 可 用 的 hint 来 获得 想 要 的 执行 计划 会 变 得 越 来 越 困难 。 


2. 指定 hint 

hint 是 Oracle 的 扩展 。 为 了 不 影响 SQL 语句 与 其 他 数据 库 引擎 的 兼容 性 ，Oracle 决 定 把 它们 作为 一 
种 特殊 的 注释 来 加 入 。 注 释 与 hint 仅 有 的 不 同 如 下 所 示 。 

口 hint 必 须 紧 随 DELETE、INSERT、MERGE 、SELECT 和 UPDATE 关 键 字 。 换 句 话 说， 它们 不 能 像 注释 那 

样 指定 在 SQL 语句 的 任意 位 置 。 

口 注释 分 隔 符 的 第 一 个 字符 必须 是 加 号 (+ )。 

一 般 而 言 ，hint 的 语法 错误 不 会 引发 报错 。 如 果 解 析 器 无 法 解析 它们 ， 就 会 把 它们 当 作 注 释 。 
有 时 ， 注 释 与 hint 混 合同 样 可 行 。 下 面 的 两 个 例子 展示 了 如 何 使 用 上 一 节 介 绍 的 查询 强制 在 emp 表 
上 执行 全 表 扫 描 : 

SELECT /*+ full(emp) */ * 


FROM emp 
WHERE empno = 7788 


SELECT /*+ full(emp) you can add a real comment after the hint */ * 
FROM emp 
WHERE empno = 7788 


然而 ， 混 合 注释 与 hint 并 不 总 是 可 行 的 。 例 如 ， 注 释 加 在 hint 前 面 就 会 使 hint 失 效 。 以 下 查询 展示 
了 这 样 的 案例 : 


SELECT /*+ but this one does not work full(emp) */ * 
FROM emp P 
WHERE empno = 7788 


因为 注释 能 使 hint 失 效 ， 所 以 不 建议 将 注释 与 hint 混 合 使 用 。 最 好 是 分 开 它们 。 


3.hint 的 类 别 

划分 hint 的 类 别 有 好 几 种 方法 ( 观点) 个 人 而 言 ， 我 喜欢 按 以 下 类 别 对 它们 进行 分 组 。 

口 初始 化 参数 hint ( initialization parameter hint ) 会 重 写 一 些 在 系统 或 会 话 级 别 定义 的 初始 化 参数 
的 设置 。 我 将 以 下 hint 划 分 在 这 个 类 别 里 : al1 rows cursor _ sharing exact、 dynamic sampling、 
first rows、 gather plan statistics、optimizer features enable 和 opt param。 我 会 在 11.4 
节 中 介绍 这 些 hint， 并 且 我 已 在 第 10 章 中 介绍 了 gather plan_statistics hint。 请 注意 ， 当 指定 
这 些 hint 时 ， 它 们 总 是 会 重 写实 例 或 会 话 级 别 的 值 。 

口 查询 转换 hint ( query transformation hint ) 控制 着 逻辑 优化 期 间 查 询 转换 技术 的 利用 率 。 我 将 以 
下 hint 划 分 在 这 个 类 别 里 : (no_)eliminate join no_expand、(no_)expand table、( no_)fact、 
(no_)merge、(no_)outer join to inner, (no )rewrite, (no )star transformation 、(no_) 
unnest、no_xmlindex_rewrite、no_xml_query_rewrite 和 use_concat。 我 会 在 后 续 几 节 介绍 部 分 
hint， 其 他 hint 会 在 第 14 章 和 第 15 章 中 进行 介绍 。 

口 访问 路 径 hint ( access path hint ) 控制 着 用 来 访问 数据 的 方法 ( 例如 ,是否 使 用 索引 )。 我 将 以 
下 hint 划 分 在 这 个 类 别 里 ; cluster、full、 hash、 (no ) index、index asc、index combine、 
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index desc、(no_) index ffs、 index join 、( no_) index ss、 index ss asc 和 index_ ss _desc。 
我 会 在 第 13 章 介绍 这 些 hint 及 其 访问 方法 。 

口 联接 hint (join hint ) 不 仅 控制 着 联接 方法 ， 也 包含 用 来 联接 表 的 顺序 。 我 将 以 下 hint 划 分 在 这 
个 类 别 里 : leading、 (no _)nlj batching、 ordered、 (no )swap join _ inputs、( no_)use_cube、 
(no )use hash、( no_) use_meTge 、use_merge_cartesian 、( no_) use_n1 和 use_nl with index。 
我 会 在 第 14 章 介绍 这 些 hint 及 其 联接 方法 。 

口 并 行 处 理 hint ( parallel processing hint ) 控制 如 何 使 用 以 及 是 否 使 用 并 行 处 理 。 我 将 以 下 hint 划 
分 在 这 个 类 别 里 : (no_) parallel (no ) parallel index 、( no_) pq_concurrent_union、 
pq_distribute pq filter、 (no )pq skew, (no )px join filter 和 (no )statement queuing。 
我 会 在 第 15 章 介绍 这 些 hint 及 其 并 行 处 理 。 在 第 14 章 中 会 随同 智能 分 区 联接 一 起 提供 
pq_distribute hint 的 一 个 可 能 利用 率 。 

口 其 他 hint 控 制 着 不 属于 上 面 任何 类 别 的 其 他 特性 。 我 将 以 下 hint 划 分 在 这 个 类 别 里 : (no ) 
append append values, (no_ )bind aware, (no_ )result cache、( no ) cache 、change_dupkey _ 
error index、driving site、 (no ) gather optimizer statistics 、ignore row on dupkey_ 
index 、inline、materialized、( no_) monitor 、model min_analysis、( no_) monitor 、qb_name 
和 retry_on_row_change。 我 会 在 本 章 稍 后 介绍 qb_name hint， 其 他 的 一 些 hint 的 介绍 会 贯穿 在 整 
本 书 中 。 

尽管 通过 本 书 我 介绍 或 展示 了 很 多 hint 的 例子 ， 但 我 并 未 提供 真实 的 参考 或 它们 完整 的 语法 。 此 

类 参考 在 Oracle Database SOL Lanaguage Reference 手 册 的 第 2 章 中 提供 。 

值得 指出 的 是 ,存在 大 量 hint 会 禁用 某 个 特殊 操作 或 特性 ( no_ 前 级 的 hint )。 好 处 是 有 时 指定 某 些 

操作 或 特性 不 可 使 用 要 更 容易 。 

以 上 提供 的 hint 列 表 并 不 完整 ,它们 只 介绍 了 记录 在 SOL Reference Guide 手 册 中 的 部 分 。 还 有 很 多 

hint 并 未 记录 在 文档 里 。 你 会 在 稍 后 的 11.6 节 中 看 到 部 分 hint。 从 11.1 版 本 起 , 可 以 查询 v$sql_hint 视 图 
来 获取 接近 完整 的 hint 列 表 。 


4.hint 的 有 效 性 
简单 的 SQL 语句 只 有 单个 查询 块 。 当 使 用 视图 或 集合 时 才 会 存在 多 个 查询 块 ， 如 子 查询 、 内 敛 视 
图 和 集合 和 运算。 例如， 以 下 查询 有 两 个 查询 块 ( 仅仅 出 于 演示 的 目的 ， 我 使 用 子 查询 来 蔡 代 一 个 真实 
的 视图 )。 第 一 个 查询 块 是 引用 dept 表 的 主 查询 。 第 二 个 是 引用 emp 表 的 子 查询 : 
WITH 
emps AS (SELECT deptno, count(*) AS cnt 
FROM emp 
GROUP BY deptno) 
SELECT dept.dname, emps.cnt 
FROM dept, emps 
WHERE dept.deptno = emps.deptno 


通常 情况 下 ， 初 始 化 参数 hint 对 整个 SQL 语句 都 有 效 ( dynamic_sampling 是 个 例外 )。 其 他 大 多 数 
hint 仅 对 单个 查询 块 有 效 ( 有 两 个 例外 ，bind_aware 和 monitor )。 对 单个 查询 块 有 效 的 hint 必 须 指 定 在 
它们 控制 的 块 内 。 例 如， 如 果 想 让 上 个 查询 里 的 两 张 表 都 指定 访问 路 径 hint， 那么 一 个 hint 需 要 加 在 主 
查询 里 ， 男 一 个 需要 加 在 子 查询 里 。 它 们 的 有 效 性 仅 限 于 它们 定义 的 查询 块 中 : 
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WITH 
emps AS (SELECT /*+ full(emp) */ deptno, count(*) AS cnt 
FROM emp 
GROUP BY deptno) 
SELECT /*+ full(dept) */ dept.dname, emps.cnt 
FROM dept, emps 
WHERE dept.deptno = emps.deptno 


这 条 规则 的 例外 是 全 局 hint ( global hint )。 使 用 全 局 hint 时 ， 有 可 能 通过 使 用 点 记 法 引用 包含 在 其 
他 查询 块 中 的 对 象 ( 如果 已 命名 它们 ) 例如， 下 面 的 SQL 语句 ， 主 查询 包含 作用 于 子 查询 的 hint。 请 
注意 子 查 询 对 引用 名 称 的 使 用 : 
WITH 
emps AS (SELECT deptno, count(*) AS cnt 
FROM emp 
GROUP BY deptno) 
SELECT /*+ full(dept) full(emps.emp) */ dept.dname, emps.cnt 
FROM dept, emps 
WHERE dept.deptno = emps.deptno 
全 局 hint 的 语法 支持 超过 两 层级 别 的 引用 (例如, 一 个 视图 引用 自 男 一 个 视图 )。 对 象 必须 要 用 点 
分 隔 开 ( 例如 ，view1.view2.view3.table )。 


提示 “全 局 hint 并 非 总 处 理 某 些 查询 转换 ， 我 建议 你 使 用 基于 查询 块 名 称 (立刻 显示 ) 的 语法 。 


由 于 WHERE 子 句 的 子 查询 不 能 命名 ， 因 此 它们 的 对 象 无 法 被 全 局 hint 引 用 。 为 了 解决 这 个 问题 ， 有 
另 一 种 方法 可 以 达到 此 目的 。 实 际 上 ,大 多 数 hint 可 以 接受 一 个 参数 ， 这 个 参数 指定 这 些 hint 对 哪个 查 
询 块 有 效 。 这 样 的 话 ，hint 可 以 在 SQL 语句 开头 被 分 组 并 且 仅 引用 它们 应 用 的 查询 块 。 要 使 用 这 些 引 
用 ， 不仅 需 要 查询 优化 器 对 每 个 查询 块 生 成 一 个 查询 块 名 称 ( query block name )， 而 且 人 允许 你 使 用 
qb_name hint 来 自 定 义 名 称 。 例 如 ， 下 面 的 查询 ， 两 个 查询 块 分 别 叫 main 和 sq。 接 着 在 full hint 里 ， 查 
询 块 名 称 通过 前 级 @ 标 识 来 引用 。 请 注意 在 主 查 询 中 指定 对 emp 表 进行 子 查 询 的 访问 路 径 hint: 
WITH 
emps AS (SELECT /*+ qb_name(sq) */ deptno, count(*) AS cnt 
FROM emp 
GROUP BY deptno) 
SELECT /*+ qb_name(main) full(@main dept) full(@sq emp) */ dept.dname, emps.cnt 
FROM dept, emps 
WHERE dept.deptno = emps.deptno 


上 一 个 例子 显示 了 如 何 指 定 自己 的 名 称 。 现 在 让 我 们 来 看 看 如 何 使 用 查询 优化 器 生成 的 名 称 。 首 
先 ， 你 必须 知道 它们 是 什么 。 为 此 ， 你 可 以 使 用 EXPLAIN PLAN 语 句 和 dbms_xplan 包 ， 如 下 面 的 例子 所 
示 。 请 注意 ，alias 选 项 被 传递 给 display 函 数 以 确保 查询 块 名 称 和 别名 是 输出 的 一 部 分 : 

SOL> EXPLAIN PLAN FOR 

2 WITH emps AS (SELECT deptno, count(*) AS cnt 


3 FROM emp 

4 GROUP BY deptno) 
5 
6 


SELECT dept.dname, emps.cnt 
FROM dept, emps 
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7 WHERE dept.deptno = emps.deptno; 


SQL> SELECT * FROM table(dbms xplan.display(NULL, NULL, 'basic +alias')); 


| SELECT STATEMENT | | 
| HASH JOIN | | 
| VIEW | | 
| HASH GROUP BY | | 
| TABLE ACCESS FULL| EMP | 
| TABLE ACCESS FULL | DEPT | 


1 =- SEL$2 
2 - SEL$1 / EMPS@SEL$2 
3 =- SEL 粒 
4 - SEL$1 / EMP@SEL$1 


5 - SEL$2 / DEPTQSEL42 ; 
系统 生成 的 查询 块 名 称 由 前 级 和 字符 串 组 成 。 前 级 是 根据 查询 块 里 的 操作 生成 的 。 表 11-2 做 了 总 
结 。 字 符 串 是 查询 块 的 编号 ， 基 于 它们 解析 SQL 语句 时 所 在 的 位 置 ( 左 或 右 )。 在 前 面 的 例子 中 ， 主 
查询 块 被 命名 为 SEL$2， 子 查询 块 被 命名 为 SEL$1。 


表 11-2 前缀 在 查询 块 名 称 中 的 使 用 


前 ” 缀 用 途 
CRI$ CREATE INDEX 语 名 
DEL$ DELETE 语 名 
INS$ INSERT 语 名 
MISC$ 其 他 SQL 语句 ， 比 如 LOCK TABLE 
MRC$ MERGE 语 句 
SELS$ SELECT 语句 
SET$ 集合 运算 符 ， 比 如 :， UNION 和 MINUS 
UPD$ UPDATE 语 名 
如 下 所 示 ， 系 统 生成 的 查询 块 名 称 的 利用 率 与 用 户 定义 的 查询 块 名 称 的 利用 率 并 无 不 同 : 
WITH 
emps AS (SELECT deptno, count(*) AS cnt 
FROM emp 


GROUP BY deptno) 
SELECT /*+ full(@sel$2 dept) full(@sel$1 emp) */ dept.dname, emps.cnt 
FROM dept, emps 
WHERE dept.deptno = emps.deptno 


我 需要 对 查询 转换 期 间 生 成 的 查询 块 名 称 做 最 后 一 次 解释 。 由 于 它们 不 是 SQL 语句 的 一 部 分 ， 因 
而 它们 无 法 像 其 他 对 象 那样 计数 。 因 此 ， 查 询 优化 器 会 为 它们 生成 8 位 的 散 列 值 。 下 面 的 例子 展示 了 
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这 种 情况 。 这 里 系统 生成 的 查询 块 名 称 为 SEL$5DA710D3: 


SQL> EXPLAIN PLAN FOR 
2 SELECT deptno 
3 FROM dept 
4 WHERE NOT EXISTS (SELECT 1 FROM emp WHERE emp.deptno = dept.deptno); 


SQL> SELECT * FROM table(dbms xplan.display(NULL,NULL, 'basic +alias')); 


| Id | Operation Name | 
0 | SELECT STATEMENT | 
1 | HASH JOIN ANTI | 
P| TABLE ACCESS FULL| DEPT | 
3 | TABLE ACCESS FULL| EMP | 


1 - SEL$5DA710D3 
2 - SEL$5DA710D3 / DEPT@SEL$1 
3 - SEL$5DA710D3 / EMP@SEL$2 


在 前 面 的 输出 中 ,会 发 现 一 件 有 趣 的 事情 ， 当 查询 转换 发 生 时 ， 执 行 计划 里 的 一 些 行 ( 比如 第 二 
行 ) 会 有 两 个 查询 块 名 称 。 它 们 都 可 以 使 用 hint。 但 是 从 查询 优化 器 的 角度 来 看 ， 仅 当 完 全 相同 的 查 
询 转 换 发 生 时 ， 查 询 转 换 之 后 的 查询 块 名 称 ( 这 里 是 SEL$5DA710D3 ) 才 可 用 。 


11.3.2 ” 何 时 使 用 


hint 的 目的 有 两 个 。 首先， 当 查 询 优化 器 不 能 自动 生成 有 效 的 执行 计划 时 ， 它 们 就 成 了 方便 的 变 
通 方法 。 这 种 情况 下 ， 你 将 用 它们 得 到 一 个 更 好 的 执行 计划 。 这 里 要 强调 的 是 ，hint 是 一 种 变通 方法 ， 
因此 不 应 该 用 在 长 期 的 解决 方案 里 。 然 而 ， 在 某 些 情况 下 ， 它 们 是 解决 问题 的 唯一 可 行 方法 。 其 次 ， 
在 查询 优化 器 对 生成 的 执行 计划 二 选 一 时 ，hint 对 评估 选择 很 有 帮助 。 这 种 情况 下 ， 可 以 使 用 它们 来 
做 模拟 分 析 。 


11.3.3 ”陷阱 和 请 误 


每 当 你 想 通 过 访问 路 径 hint 、 联 接 hint 或 并 行 处 理 hint 来 锁定 某 个 特定 的 执行 计划 时 ， 必 须 指 定 足 
够 的 hint 来 实现 稳定 性 。 这 里 的 稳定 性 表示 即使 在 一 定 程度 上 ， 对 象 的 统计 信息 和 访问 结构 发 生 了 改 
变 ， 执 行 计 划 也 不 会 改变 。 要 锁定 某 一 执行 计划 ， 正 常情 况 下 不 仅 要 给 SQL 语句 里 的 每 张 表 添加 访问 
路 径 hint， 还 要 添加 多 个 联接 hint 来 控制 联接 方法 和 顺序 。 请 注意 ， 其 他 类 型 的 hint ( 比如 ， 初 始 化 参 
数 hint 和 查询 转换 hint ) 通常 不 会 受到 此 问题 的 影响 。 

当 处 理 SQL 语 名 时 ， 解 析 器 会 检查 hint 的 语法 。 尽 管 如 此 ， 当 发 现 hint 有 无 效 的 语法 时 ， 除 非 是 行 
为 奇怪 的 change_dupkey error index、ignore row on dupkey inddex 和 retry on row_change 等 hint， 否 
则 并 不 会 引发 报错 。 这 代表 解析 需 把 这 个 假 hint 当 作 注 释 来 处 理 。 从 一 方面 看 ， 仅 仅 因为 输入 错误 造 
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成 hint 不 可 使 用 很 让 人 恼火 。 但 男 一 方面 ,这 对 已 经 部 署 好 的 应 用 有 益 ， 比 如 经 常会 在 hint 里 引用 对 象 
( 比如 ，index hint 会 引用 索引 名 称 ) 或 升级 到 新 的 数据 库 版 本 ， 都 不 会 因为 访问 结构 的 改变 而 引起 中 
汤 。 即 便 如 此 ， 我 还 是 想 要 一 种 可 以 检验 SQL 语 名 里 hint 的 方法 。 比 如 ， 通 过 EXPLAIN PLAN 语句 ， 在 这 
方面 提供 一 个 警告 ( 比如 ， 在 dbms_xplan 的 输出 中 多 了 条 记录 ) 是 非常 简单 的 。 我 所 知道 的 唯一 能 部 
分 实现 该 功能 的 方法 就 是 设置 10132 事 件 。 实际 上 ， 该 事件 生成 的 数据 结尾 部 分 就 是 留 给 hint 的 。 你 可 
以 在 这 部 分 检查 两 件 事 。 首 先 ， 每 个 hint 都 会 被 列 出 。 如 果 有 hint 不 在 ， 这 代表 并 没有 被 识别 。 其 次 ， 
检查 是 否 存 在 一 条 通知 某 些 hint 有 错误 的 消息 。( 在 这 种 情况 下 ， 会 将 err 字 段 设 置 为 大 于 0 的 值 )。 请 
注意 ， 为 了 获得 下 面 的 输出 ， 已 指定 了 两 个 彼此 冲突 的 初始 化 参数 : 


Dumping Hints 


atom hint=(@=0x6b796498 err=4 resol=0 Used=0 token=454 org=1 lvl=1 txt=ALL ROWS ) 
atom hint=(@=0x6b796578 err=4 resol=0 used=0 token=453 org=1 lvl=1 txt=FIRST ROWS ) 
计 六 本 村 本 水 汪 站 玉 水 WARNING: “SOME HINTS HAVE ERRORS 市 站 水 闵 亲 冰 水 水 六 


请 注意 ,使 用 这 种 方法 的 话 ，hint 语 法 正确 ,但 是 引用 了 错误 的 对 象 并 不 会 报错 。 因 此 ， 这 不 是 
最 终 解决 方案 。 

hint 使 用 中 最 常见 的 错误 都 与 表 别 名 有 关 。 规则 是 当 hint 引 用 一 张 表 时 ,只 要 表 有 别名 就 应 该 使 用 
别名 代 蔡 表 名 。 在 下 面 的 例子 中 ， 可 以 看 到 如 何 为 emp 表 定义 别名 (e)。 在 这 种 情况 下 ， 当 full hint 
引用 表 名 时 ， 这 个 hint 不 会 起 作用 。 请 注意 ,在 第 一 个 例子 里 使 用 了 索引 扫描 而 不 是 期 望 的 全 表 扫描 : 

SQL EXPLAIN PLAN FOR SELECT /*+ full(emp) */ * FROM emp e WHERE empno = 7788; 


SQL> SELECT * FROM table(dbms xplan.display(NULL,NULL，basic')); 


| Id | Operation | Name | 


| 0 | SELECT STATEMENT | 
| 1| TABLE ACCESS BY INDEX ROWID| EMP | 
| 2 | INDEX UNIOUE SCAN | EMP_PK | 


SOL> EXPLAIN PLAN FOR SELECT /*+ full(e) */ * FROM emp e WHERE empno = 7788; 


SQL> SELECT * FROM table(dbms xplan.display(null,null,'basic')); 


| 0 | SELECT STATEMENT | | 
| 1| TABLE ACCESS FULL| EMpP | 


升级 期 间 应 该 检查 hint 的 影响 , 但 是 却 总 是 会 被 忘记 。 查 询 优 化 右 不 会 自动 提供 高 效 的 执行 计划 ， 
而 是 根据 查询 优化 器 使 用 的 决策 树 类 型 来 决定 效果 ， 这 时 hint 就 是 一 种 方便 的 变通 方法 ; 任何 时 候 加 
过 hint 的 SQL 语句 要 在 另 一 个 版 本 的 数据 库 (并 且 因 此 使 用 了 另 一 版 本 的 查询 优化 器 ) 上 执行 ， 都 要 
进行 仔细 检查 。 换 名 话说 ， 当 检验 新 版 本 数据 库 上 的 应 用 时 ， 最 好 的 解决 方案 是 重新 检查 并 且 重 测 所 
有 包含 hint 的 SQL 语句 。 出 于 测试 目的 ， 也 应 该 在 会 话 级 别 把 未 公开 的 初始 化 参数 optimizer _ 
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ignore_hints 设 置 为 TRUE 来 禁用 所 有 的 hint。 请 注意 ,要 避免 在 系统 级 别 设置 该 参数 ， 因 为 数据 库 引 擎 
自身 也 会 用 到 许多 hint。 

由 于 视图 可 能 会 用 于 不 同 的 环境 ， 因 此 不 建议 在 视图 中 指定 hint。 如 果真 的 想 在 视图 中 添加 hint， 
确保 加 入 的 hint 对 所 有 模块 都 有 意义 。 


11.4 ”修改 执行 环境 


第 9 章 介 绍 了 如 何 配置 查询 优化 器 。 该 配置 就 是 所 有 用 户 连接 到 数据 库 引 擎 的 默认 执行 环境 。 因 
此 ， 它 必须 适合 于 大 多 数 情况 。 当 多 个 应 用 使 用 数据 库 时 〈 例 如， 由 于 数据 库 服 务 器 整合 ) 或 单个 应 
用 基于 模块 需要 不 同 环境 时 (例如 ， 和 白天 的 OLTP 和 夜晚 的 批 处 理 )， 单 独 一 个 环境 无 法 满足 所 有 场景 
是 很 常见 的 。 这 种 情况 下 ， 在 会 话 级 别 甚 至 SQL 语句 级 别 修改 执行 环境 是 恰当 的 。 


11.4.1 工作 原理 


在 会 话 级 别 修改 执行 环境 与 在 SQL 语句 级 别 修改 完全 不 同 。 因 此 , 我 会 分 别 介绍 两 种 情况 。 此 外 ， 
我 会 介绍 一 些 显示 数据 库 实 例 、 单 个 会 话 或 子 游标 相关 环境 的 动态 性 能 视图 。 


1. 会 话 级 别 

第 9 章 介 绍 的 大 多 数 初始 化 参数 都 可 以 在 会 话 级 别 使 用 ALTER SESSION 语 句 进行 修改 。 因 此 ， 如 果 
你 有 用 户 或 者 模块 需要 特殊 配置 ， 可 以 简单 地 在 会 话 级 别 更 改 默 认 值 。 例 如 ， 根 据 连接 到 数据 库 的 用 
户 来 设置 执行 环境 ， 可 以 使 用 配置 表 和 数据 库 触 发 器 ， 如 下 面 的 例子 所 示 。 可 以 在 exec_env_trigger. 
sql 脚 本 中 找到 该 SQL 语句 : 

CREATE TABLE exec_env_conf (username VARCHAR2(30), 


parameter VARCHAR2(80), 
value VARCHAR2(512)) 


CREATE OR REPLACE TRIGGER execution environment AFTER LOGON ON DATABASE 
BEGIN 
FOR c IN (SELECT parameter, value 
FROM exec env_conf 
WHERE username = sys_context('userenv','session user')) 
LOOP 
EXECUTE IMMEDIATE 'ALTER SESSION SET ' || c.parameter || '=" || c.value; 
END LOOP; 
END; 


接着 针对 需要 某 个 特别 配置 的 每 个 用 户 , 应 该 为 每 个 初始 化 参数 在 配置 表 里 插 入 一 行 数据 ,例如 ， 
当 名 叫 Alberto 的 用 户 登 录 时 ， 下 面 两 个 INSERT 语 句 会 在 会 话 级 别 更 改 和 定义 两 个 参数 : 

INSERT INTO exec env conf VALUES ('ALBERTO', 'optimizer mode', 'first rows 10') 

INSERT INTO exec env conf VALUES ('ALBERTO', 'optimizer dynamic sampling', '0') 

当然 ， 也 可 以 为 单个 模式 定义 触发 器 ， 或 执行 基于 诸如 userenv 上 下 文 的 其 他 检查 。 
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2. SQL 语句 级 别 

SQL 语句 级 别 的 执行 环境 通过 初始 化 参数 hint 来 更 改 。 由 于 使 用 hint， 因 此 之 前 介绍 的 hint 的 行为 
和 性 能 都 会 生效 。 

并 不 是 所 有 的 初始 化 参数 组 成 的 查询 优化 器 配置 都 可 以 在 SQL 语句 级 别 上 修改 。 表 11-3 总 结 了 在 
SQL 语句 级 别 上 哪些 参数 和 值 与 初始 化 参数 hint 一 样 可 以 实现 相同 的 配置 。 请 注意 对 于 某 些 初始 化 参 
数 (比如 ，cursor_sharing ) 来 说 ， 并 不 是 所 有 的 值 都 可 以 使 用 hint 来 设置 。 


表 11-3 ”SQL 语句 级 别 hint 可 修改 的 查询 优化 器 配置 


初始 化 参数 hint 
Cursor sharing=exact CUISOT sharing exact 
optimizer dynamic sampling=x dynamic sampling(x) 
optimizer features enable=x optimizer features enable('x') 
optimizer features enable not set optimizer features enable(default) 
optimizer index caching=x opt_param('optimizer index caching' x) 
optimizer index cost adj=x opt_param('optimizer index cost adj' x) 
optimizer mode=all rows all rows 
optimizer mode=first rows first rows 
optimizer mode=first rows x first rows(x) 
optimizer Secure view merging=x 4 opt param('optimizer secure view merging' 'x') 
optimizer use pending statistics=x opt_param('optimizer use pending statistics' ‘x') 
result cache mode=manual no_result_ cache 
result cache mode=force result cache 
star transformation enabled=x opt param('star transformation enabled' 'x') 


3. 动态 性 能 视图 

有 以 下 三 个 动态 性 能 视图 提供 执行 环境 的 信息 。 

口 v$sys_optimizer_env 提 供 实 例 级 别 的 执行 环境 信息 。 例 如 ， 可 以 找 出 哪个 初始 化 参数 没有 设 
置 成 默认 值 : 


SQL> SELECT name, value, default value 


2 
3 


FROM v$sys optimizer env 
WHERE isdefault = 'NO'; 


VALUE DEFAULT VALUE 


star transformation enabled true false 
口 v$ses_optimizer_env 提 供 每 个 会 话 的 执行 环境 信息 。 由 于 没有 列 提供 某 个 初始 化 参数 是 否 在 
系统 或 会 话 级 别 被 修改 的 信息 ， 因 此 可 以 使 用 以 下 查询 达到 目的 : 


SQL> SELECT name, value 


2 


ON 


NAME 


FROM v$ses optimizer env 

WHERE sid = 124 AND isdefault = “NO 
MINUS 

SELECT name, value 

FROM v$sys optimizer env; 


VALUE 
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cursor _ sharing force 
optimizer mode first rows 10 


口 v$sql_optimizer_env 提 供 库 缓存 中 存在 的 每 个 子 游标 的 执行 环境 信息 。 比 如 ， 以 下 查询 可 以 
查 明 同一 父 游标 的 两 个 子 游标 是 否 使 用 不 同 的 执行 环境 : 


SOL> SELECT e0.name，e0.Vvalue AS value child 0, ei1.value AS value child 1 
2 FROM v$sql optimizer env eo0, v$sql optimizer env el 
3 WHERE e0.Sql id = ei1.sql id 
4 AND e0.sql id = 'asks9fhw2v9s1' 
5 AND eo.child number = 0 
6 AND el1.child number = 1 
7 AND eo.name = el.name 
8 AND e0.value <> el.valuei 


NAME VALUE CHILD 0 VALUE CHILD 1 
hash area size 33554432 131072 
optimizer mode first rows 10 all rows 
cursor sharing force exact 
workarea_size policy manual auto 


11.4.2” 何 时 使 用 


每 当 默认 配置 无 法 满足 应 用 的 某 一 部 分 或 部 分 用 户 时 ， 就 应 该 修改 默认 配置 。 尽 管 在 会 话 级 别 初 
始 化 参数 随时 都 可 以 修改 ， 但 hint 只 有 在 修改 SQL 语句 级 别 时 才 有 效 。 


11.4.3 ”陷阱 和 说 误 


可 以 将 设置 集中 在 数据 库 或 应 用 中 时 ， 在 会 话 级 别 修改 执行 环境 是 非常 简单 的 。 如 果 使 用 的 应 用 
或 模块 共享 的 连接 池 需 要 不 同 的 执行 环境 ， 你 需要 额外 注意 。 实 际 上 ， 会话 参数 与 物理 连接 有 关 。 册 
于 其 他 应 用 或 模块 会 使 用 物理 连接 , 每 次 从 连接 池 获 取 到 连接 都 要 设置 一 次 执行 环境 ( 当然 代价 很 高 ， 
因为 需要 额外 反复 连接 数据 库 )。 如 果 有 的 应 用 或 者 模块 需要 不 同 的 执行 环境 ， 为 了 避免 这 种 开销 ， 
应 该 使 用 不 同 的 连接 池 和 不 同 的 用 户 。 这 样 ， 就 可 以 针对 每 个 连接 池 使 用 单独 的 配置 ， 并 且 通 过 定义 
不 同 的 用 户 连 接 到 数据 库 ， 你 也 许 能 够 将 配置 集中 到 一 个 简单 的 数据 库 触 发 器 中 。 

在 SQL 语 句 级 别 修 改 执行 环境 也 存在 与 hint 一 样 的 误区 和 诬 误 。 


11.5 ”存储 概要 


存储 概要 的 作用 是 ， 在 执行 环境 或 对 象 统计 信息 中 存在 更 改 时 ， 提 供 稳 定 的 执行 计划 。 为 此 ， 这 
个 功能 也 称 为 计划 稳定 性 ( plan stability ). 在 Oracle 文 档 中 记录 了 体现 该 功能 优势 的 两 个 重要 场景 。 第 
一 个 是 从 基于 规则 的 优化 器 ( RBO ) 向 基于 成 本 的 优化 器 ( CBO ) 的 迁移 。 第 二 个 场景 是 将 Oracle 数 
据 库 升 级 到 新 版 本 。 在 这 两 个 场景 中 , 目的 都 是 在 应 用 使 用 旧 配 置 或 版 本 时 存储 关于 执行 计划 的 信息 ， 
然后 使 用 该 信息 来 提供 与 新 的 配置 或 版 本 相同 的 执行 计划 。 不 幸 的 是 ,实际 上 即使 正确 地 使 用 存储 概 
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要 ( stored outline )， 你 仍 能 看 到 执行 计划 在 改变 。 或 许 是 由 于 这 个 原因 ， 我 从 未 见 过 哪个 数据 库 大 范 
围 地 使 用 存储 概要 。 因 此 ， 实 际 上 存储 概要 仅 会 用 在 某 些 具体 的 SQL 语句 上 。 


注意 从 11.1 版 本 之 后 ， 存 储 概 要 不 再 支持 SQL 计划 管理 (SQL plan management ) ( 本 章 稍 后 会 
介绍 ) 


11.5.1 工作 原理 
接 下 来 的 几 部 分 会 介绍 什么 是 存储 概要 以 及 如 何 使 用 它们 。 


1. 什么 是 存储 概要 

存储 概要 是 与 SQL 语句 相关 联 的 对 象 ， 其 作用 是 在 为 SQL 语句 生成 执行 计划 时 影响 查询 优化 器 。 
更 具体 地 说 ， 存 储 概要 是 一 组 hint， 或 者 更 准确 地 说 ， 是 所 有 能 强制 查询 优化 右 始 终 为 给 定 SQL 语 句 
生成 特定 执行 计划 的 hint 组 合 。 


注意 并 不 是 所 有 hint 都 可 以 保存 在 存储 概要 中 要 想 知道 不 
能 保存 哪些 hint， 可 以 执行 以 下 查询 : 
SELECT name FROM v$sql hint WHERE version outline IS NULL 
尽管 大 多 数 无 法 保存 到 存储 概要 中 的 hint 不 会 影响 执行 
计划 (例如 gather plan statistics )， 但 有 些 还 是 会 的 
(例如 materialize 和 inline )。 因 此 ， 有 些 执行 计划 因 无 
法 在 SQL 语句 中 指定 hint 而 不 能 通过 存储 概要 固定 


基于 SQL 语句 签名 
查找 存储 概要 


否 存储 概要 

是 否 可 用 

是 
包含 存储 概要 HINT 


存储 概要 的 优势 之 一 是 ， 当 它 应 用 于 某 个 SQL 语句 时 ， 你 
并 不 需要 为 了 应 用 存储 概要 而 修改 SQL 语 句 。 存 储 概要 保存 在 
数据 字典 里 ， 并 且 查 询 优 化 器 会 自动 选择 它们 。 图 11-2 显 示 了 
在 选择 期 间 执行 的 基本 步 又。 首先 ， 会 将 SQL 语 句 中 的 空格 移 
除 ， 进 行 标准 化 ， 并 将 非 文字 字符 串 转换 为 大 写 。 作 为 结果 的 
SQL 语句 签名 ( SQL 语句 文本 的 散 列 值 ) 会 被 计算 。 接 着 ， 根 
据 签 名 ， 在 数据 字典 里 执行 查找 。 每 当 找到 包含 同样 签名 的 存 
储 概要 时 ， 就 会 执行 检查 来 确保 这 个 SQL 语句 是 最 优 的 ， 并 且 
与 绑 定 存储 概要 的 SQL 语句 是 等 价 的。 这 一 步 很 重要 ， 因 为 签 


号 
名 是 散 列 值 , 可 能 会 产生 冲突 。 如 果 测 试 成 功 , 那么 hint 组 成 的 


存储 概要 就 会 包含 在 生成 的 执行 计划 里 。 图 11-2 选择 存储 概要 期 间 要 执行 
2. 创建 存储 概要 的 主要 步 又 
可 以 使 用 两 种 方法 来 创建 存储 概要 。 数 据 库 上 自动 创建 和 手工 创建 。 如 果 想 为 指定 会 话 甚至 整个 系 
统 执行 的 每 条 SQL 语句 创建 存储 概要 ， 可 以 使 用 第 一 种 方法 。 然 而 ， 就 像 前 面 提 到 的 ， 通 常 没有 必要 
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这 么 做 。 因 此 ， 经 常会 手工 创建 它们 。 

要 激活 自动 创建 ， 需 要 将 初始 化 参数 create_stored outlines 设 置 为 TRUE 或 者 指定 一 个 类 别 
(category )。 使 用 类 别 的 目的 是 要 集合 多 个 存储 概要 来 实现 统一 管理 。 将 初始 化 参数 设置 为 TRUE 时 会 使 
用 默认 类 别 , 其 名 称 为 DEFAULT。 可 以 在 会 话 级 别 和 系统 级 别 动态 更 改 该 初始 化 参数 。 要 禁用 自动 创建 ， 
需要 将 初始 化 参数 设置 为 FALSE。 

要 手工 创建 存储 概要 ， 必 须 使 用 CREATE OUTLINE 语 句 。 下 面 的 SQL 语句 ， 摘 录 自 outline from_ 
text.sql 脚 本 ， 展 示 了 名 为 outline_from_text 的 存储 概要 的 创建 ， 该 存储 概要 与 test 类 别 相 关联 ， 并 
基于 ON 子 句 中 指定 的 查询 : 

CREATE OR REPLACE OUTLINE outline from text 


FOR CATEGORY test 
ON SELECT * FROM t WHERE n = 1970 


一 旦 创建 好 ， 就 可 以 通过 user outlines 和 user outline_hints 视 图 来 显示 存储 概要 的 信息 和 它们 
的 属性 ( 对 于 这 两 个 视图 ， 也 存在 以 all 、dba 开 头 的 视图 ， 同时， 在 12.1 多 租户 环境 下 还 有 以 cdb 开 头 
的 视图 )。User_outlines 视 图 显示 除了 hint 以 外 的 信息 。 下 面 的 查询 显示 的 信息 为 上 一 个 SQL 语句 创建 
的 存储 概要 : 

SQL> SELECT category, sql text, signature 


2 FROM user outlines 
3 WHERE name = 'OUTLINE FROM TEXT'; 


CATEGORY SQL TEXT SIGNATURE 


TEST SELECT * FROM t WHERE n = 1970 73DC40455AF10A40D84EF59A2F8CBFFE 


SQL> SELECT hint 
2 FROM user outline hints 
3 WHERE name = "OUTLINE FROM TEXT'; 


FULL(@"SEL$1" "T"@"SEL$1") 
OUTLINE_LEAF(@"SEL$1") 

ALL_ROWS 

DB_VERSION('11.2.0.3') 
OPTIMIZER_FEATURES ENABLE('11.2.0.3') 
IGNORE_OPTIM EMBEDDED_HINTS 


也 可 以 通过 引用 库 缓存 里 的 游标 来 手工 创建 存储 概要 。 下 面 的 例子 ， 摘 录 自 outline from_ 
sqlarea.sql 脚 本 生成 的 输出 ， 显 示 了 如 何 从 闫 缓存 里 选择 游标 并 且 通 过 dbms_outln 包 下 的 create_ 
outline 过 程 创建 存储 概要 : 

SQL> SELECT hash value, child number 


2 FROM v$sql 
3 WHERE sql text = 'SELECT * FROM t WHERE n = 1970'; 


HASH VALUE CHILD NUMBER 


308120306 0 
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SOL> BEGIN 
2 dbms_outln.create outline(hash value => '308120306', 
child number =>0， 
category =y "test' )s 
END; 
# 


GOn 上 wo 


警告 ”create _outline 过 程 不 会 基于 与 引用 的 游标 相关 联 的 执行 计划 创建 存储 概要 。 相 反 ， 它 接受 与 
游标 相关 联 的 SQL 语句 的 文本 并 重 解析 它 。 因 此 , 与 存储 概要 相关 联 的 执行 计划 并 不 需要 和 与 
游标 相关 联 的 执行 计划 一 致 。 例 如 ， 一 个 不 同 的 执行 环境 可 以 很 容易 导致 另 一 个 执行 计划 。 


如 下 所 示 ，create_outline 过 程 仅 接受 三 个 参数 。 这 代表 存储 概要 的 名 称 是 自动 生成 的 。 要 找 出 
系统 生成 的 名 称 ， 需 要 查询 视图 ， 比 如 user outlines。 下 面 的 查询 返回 最 后 创建 的 存储 概要 名 : 


SOL> SELECT name 
2 FROM user outlines 
3 WHERE timestamp = (SELECT max(timestamp) FROM user outlines); 


NAME z 


SYS_OUTLINE 13072411155434901 


系统 自动 生成 的 存储 概要 名 称 是 可 以 自 定义 的 。 下 一 部 分 将 介绍 如 何 修 改 。 


3. 修改 存储 概要 

要 更 改 存储 概要 名 ， 需 要 执行 ALTER 0UTLINE 请 句 : 

ALTER OUTLINE SYS_OUTLINE 13072411155434901 RENAME TO outline from sqlarea 

使 用 ALTER OUTLINE 语 句 或 dbms_out1n 包 下 的 update_by_cat 过 程 ， 也 可 以 修改 存储 概要 的 类 别 。 然 
而 前 者 修改 单个 存储 概要 的 类 别 ， 后 者 把 所 有 属于 一 个 类 别 的 存储 概要 都 移动 到 另 一 个 类 别 中 。 可 是 
由 于 bug 5759631， 使 用 ALTER OUTLINE 不 能 修改 存储 概要 类 别 DEFAULT ( 对 于 其 他 类 别 ， 不 存在 这 个 问 
题 )。 下 面 的 例子 介绍 了 当 你 尝试 修改 时 会 发 生 什么， 同时 还 介绍 了 如 何 使 用 update_by_cat 过 程 执行 
同样 的 操作 : 


SQL> ALTER OUTLINE outline from text CHANGE CATEGORY TO DEFAULT; 
ALTER OUTLINE outline from text CHANGE CATEGORY TO DEFAULT 
党 


ERROR at line 1: 
ORA-00931: missing identifier 


SQL> execute dbms outln.update by cat(oldcat => 'TEST', newcat => 'DEFAULT') 
SOL> SELECT category 
2 FROM user outlines 


3 WHERE name = 'OUTLINE FROM TEXT ; 


CATEGORY 
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DEFAULT 
最 后 ， 使 用 ALTER OUTLINE 语 句 ， 也 可 以 生成 存储 概要 ， 就 像 重 建 一 样 。 通 常情 况 下 ， 会 在 想 要 查 
询 优化 器 生成 一 组 新 的 hint 时 使 用 该 语句 。 如 果 更 改 了 与 存储 概要 相关 的 对 象 的 访问 结构 ， 可 能 有 必 
要 使 用 该 语句 : 
ALTER OUTLINE outline from_ text REBUILD 


4. 激活 存储 概要 

只 有 在 存储 概要 被 激活 后 查询 优化 器 才 会 处 理 。 要 激活 它 ， 存 储 概 要 需要 满足 两 个 条 件 。 第 一 ， 
存储 概要 必须 是 启用 的 。 在 创建 存储 概要 时 ， 默 认 是 启用 的 。 要 启用 和 停 用 存储 概要 ,可 以 使 用 ALTER 
OUTLINE 语 句 : 

ALTER OUTLINE outline from text DISABLE 


ALTER OUTLINE outline from text ENABLE 

第 二 个 条 件 是 类 别 〈 category ) 必须 在 会 话 或 系统 级 别 通过 初始 化 参数 use_stored_outlines 来 激 
活 。 初 始 化 参数 可 以 接受 的 值 为 TRUE 、FALSE 或 类 别名 。 如 果 指 定 TRUE ， 类 别 默 认 值 为 DEFAULT。 以 下 
SQL 语句 在 会 话 级 别 激活 属于 test 类 别 的 存储 概要 : 

ALTER SESSION SET use stored outlines = test 

由 于 初始 化 参数 use_stored_ outlines 只 支持 单个 类 别 ,因此 在 同一 时 间 一 个 会 话 只 能 激活 一 个 类 别 

要 想 知道 查询 优化 器 是 否 使 用 了 存储 概要 ， 可 以 利用 dbms_xplan 包 下 的 函数 。 实 际 上 ， 正 如 下 而 
的 例子 所 示 ， 输 出 的 Note 部 分 明确 提供 了 需要 的 信息 : 

SQL> EXPLAIN PLAN FOR SELECT * FROM t WHERE mn = 1970; 


SQL> SELECT * FROM table(dbms xplan.display); 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
|* 1 | TABLE ACCESS FULLIT | 


- outline "OUTLINE FROM TEXT”used for this statement 
对 于 库 缓 存 中 存储 的 游标 ，v$sql 视 图 的 outline_category 列 会 指明 在 执行 计划 生成 期 间 是 否 使 用 
了 存储 概要 。 不 幸 的 是 ， 这 只 给 出 了 类 别名 。 存 储 概要 名 本 身 却 是 未 知 的 。 如 果 没 有 使 用 存储 概要 ， 
该 列 将 会 是 NULL。 
有 一 种 方法 可 以 知道 在 一 段 时 间 内 是 否 使 用 过 存储 概要 ， 可 以 使 用 dbms_outln 包 下 的 clear_used 
过 程 来 重 置 使 用 标记 。 接 着 ， 稍 后 再 查看 该 标记 ， 就 可 以 判断 是 否 使 用 了 这 个 存储 概要 。 然 而， 并 不 
会 给 出 更 多 的 使 用 信息 ( 比如 ， 使 用 次 数 或 何 时 使 用 ): : 
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SOL> execute dbms_ outln.clear used(name => "OUTLINE_FROM_TEXT ) 


SQL> SELECT used 
2 FROM user outlines 
3 WHERE name = "OUTLINE FROM TEXT ; 


UNUSED 
SQL> SELECT * FROM t WHERE n = 1970; 


SOL> SELECT used 
2 FROM user outlines 
3 WHERE name = "OUTLINE FROM TEXT'; 


5. 移动 存储 概要 

Oracle 并 没有 提供 用 于 移动 存储 概要 的 特别 功能 。 基 本 上 ， 必 须 自 己 从 一 个 数据 字典 复制 到 另 一 
个 数据 字典。 这 比较 简单 ， 因 为 数据 只 保存 在 了 outln 模 式 的 三 个 表 中 : ol$、ol$hints 和 ol$nodes。 
可 以 使 用 下 面 的 命令 来 导入 和 导出 所 有 可 用 的 存储 概要 


exp tables=(outln.o1$,outln.ol$hints,outln.ol$nodes) file=outln.dmp 


imp full=y ignore=y file=outln.dmp 

要 想 移动 单个 的 存储 概要 ( 此 例 中 为 outline_from text )， 可 以 给 export 命 令 添加 以 下 参数 : 

要 想 移 动 一 个 类 别 ( 这 里 使 用 test 类 别 ) 下 的 所 有 存储 概要 ， 可 以 给 export 命 令 添加 以 下 参数 : 

query="WHERE Category= "TEST ” 

请 小 心 , 因为 根据 使 用 的 操作 系统 和 shell, 你 可 能 必须 添加 某 些 转 义 字符 才能 成 功 传递 所 有 参数 。 
例如 ， 在 Linux 服 务 器 上 ， 使 用 bash 时 ， 我 必须 执行 以 下 命令 : 


exp tables=\(outln.ol\$,outln.ol\$hints,outln.ol\$nodes\) file=outln.dmp \ 
query=\"WHERE ol_name=\ "OUTLINE_FROM TEXT\'\" 


6. 编辑 存储 概要 

使 用 存储 概要 可 以 锁定 执行 计划 。 然 而 ， 只 有 在 查询 优化 器 能 够 生成 高 效 执行 计划 并 且 稍 后 捕捉 
到 并 由 存储 概要 锁定 才 有 用 。 如 果 不 是 这 种 情况 ， 首 先 你 需要 研究 的 是 ， 为 了 创建 保存 高 效 执行 计划 
的 存储 概要 ， 是 否 有 可 能 修改 执行 环境 、 访 问 结构 或 对 象 的 统计 信息 。 比 如 ， 给 定 SQL 语 句 的 执行 计 
划 使 用 了 索引 扫描 ,而 你 想 避 免 使 用 它 , 那 就 应 该 在 测试 系统 上 删除 (或 隐藏 ) 索引 , 生成 存储 概要 ， 
然后 移动 到 生产 环境 中 。 

当 你 发 现 无 法 强制 查询 优化 器 自动 生成 一 个 高 效 的 执行 计划 时 ， 最 后 的 手段 是 手工 修改 存储 概 
要 。 简 单 地 说 ， 你 需要 修改 与 存储 概要 相关 联 的 hint。 然 而 在 实践 中 ， 你 无 法 对 保存 在 数据 字典 中 的 
公共 存储 概要 ( public stored outline ) ( 这 是 到 目前 为 止 我 们 讨论 的 存储 概要 种 类 ) 简 单 地 运行 几 个 SQL 
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语句 。 相 反 ， 你 必须 执行 像 图 11-3 总 结 的 那样 的 修改 。 这 个 过 程 是 基于 私有 存储 概要 ( private stored 
outline ) 的 修改 。 这 些 与 公共 存储 概要 类 似 ， 但 不 是 保存 在 数据 字典 中 ， 而 是 保存 在 工作 表 ( working 
table ) 中 。 使 用 工作 表 的 目的 就 是 为 了 避免 直接 修改 数据 字典 。 因 此 ， 要 修改 存储 概要 ,你 需要 创建 、 


修改 并 测试 私有 存储 概要 。 接 着 ， 当 私有 存储 概要 工作 正常 后 ， 就 把 它 改 成 公共 存储 概要 。 
Dbms_outln_edit 包 和 CREATE OUTLINE 语 句 的 一 些 扩展 都 可 以 修改 存储 概要 。 


创建 私有 存储 概要 
更 新 私有 存储 概要 


刷新 内 存 中 私有 
存储 概要 的 副本 


测试 私有 存储 概要 
私有 概要 是 否 工作 ? 


是 


发 布 私有 存储 概要 
为 公共 存储 概要 


图 11-3 ”修改 存储 概要 期 间 执行 的 步 又 


根据 outline_editing.sql 脚 本 中 的 例子 ， 我 来 介绍 图 11-3 总 结 的 整个 过 程 。 目 的 是 为 以 下 查询 创 
建 和 修改 存储 概要 ， 来 用 索引 扫描 替代 全 表 扫描 : 


SQL> EXPLAIN PLAN FOR SELECT * FROM t WHERE n = 1970; 


SQL> SELECT * FROM table(dbms xplan.display(NULL,NULL, 'basic')); 
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| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 
| 2| INDEX RANGE SCAN 和 | 


首先 ， 需 要 创建 私有 存储 概要 。 因 此 ， 会 遇 到 两 种 情况 。 第 一 种 情况 是 像 以 下 SQL 语句 那样 重新 
创建 私有 存储 概要 。PRIVATE 关 键 字 指定 了 要 创建 的 存储 概要 类 型 : 


SQL> CREATE OR REPLACE PRIVATE OUTLINE p outline editing 
2 ON SELECT * FROM t WHERE n = 1970; 


第 二 种 情况 是 借助 于 类 似 以 下 SQL 语 句 复制 已 经 存在 于 数据 字典 中 的 公共 存储 概要 。PRIVATE 和 
PUBLIC 关 键 字 分 别 指定 了 需要 创建 和 复制 的 存储 概要 类 型 : 

SOL> CREATE PRIVATE OUTLINE p outline editing FROM PUBLIC outline editing; 

两 种 方法 都 会 在 工作 表 里 创 建 私有 存储 概要 。 下 面 是 与 存储 概要 相关 的 hint 列 表 : 


SQL> SELECT hint text 
2 FROM ol$hints 
3 WHERE ol name = 'P_OUTLINE EDITING'; 


HINT_TEXT 


INDEX_RS ASC(@"SEL$1" "T"@"SEL$1" ("T"."N")) 
OUTLINE LEAF(@"SEL$1") 

ALL_ROWS 

DB_VERSION('11.2.0.3') 

OPTIMIZER_FEATURES ENABLE('11.2.0.3') 
IGNORE_OPTIM EMBEDDED_HINTS 


一 旦 创建 好 私有 存储 概要 ,就 可 以 使 用 常规 DML 语 句 修 改 它 。 人 然而, 想 要 修改 覆盖 所 有 需求 并 不 
是 容易 的 事 。 一 个 比较 容易 实现 的 办 法 是 再 创建 一 个 私有 存储 概要 来 复制 想 要 的 执行 计划 ， 然 后 交换 
这 两 个 执行 计划 的 内 容 。 要 创建 附加 存储 概要 ， 需 要 执行 以 下 SQL 语句 。 请 注意 ，hint 是 用 来 命令 查 
询 使 用 全 表 扫描 的 : 


SQL CREATE OR REPLACE PRIVATE OUTLINE p_outline_editing_hinted 
2 ON SELECT /*+ full(t) */ * FROM t WHERE n = 1970; 


然后 通过 执行 如 下 SQL 语 句 来 交换 内 容 : 
SQL> UPDATE ol$ 


2 SET hintcount = (SELECT hintcount 

3 FROM ol$ 

4 WHERE ol name = 'P_OUTLINE EDITING HINTED') 
5 WHERE ol name = 'P_OUTLINE EDITING'; 


SQL> DELETE ol$hints 
2 WHERE ol name = "P_OUTLINE_EDITING ; 


SOL> UPDATE ol$hints 
2 SET ol name = 'P_OUTLINE EDITING' 
3 WHERE ol name = 'P_OUTLINE EDITING HINTED'; 
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下 面 是 交换 完 后 与 私有 存储 概要 相关 联 的 hint 列 表 。 唯 一 的 不 同 就 是 index hint 被 替换 成 了 full hint: 


SQL> SELECT hint text 
2 FROM ol$hints 
3 WHERE ol name = 'P_OUTLINE EDITING'; 


HINT_TEXT 


FULL(@"SEL$1" "T"@"SEL$1") 

OUTLINE LEAF(@"SEL$1") 

ALL ROWS 

DB_VERSION('11.2.0.3') 

OPTIMIZER FEATURES ENABLE('11.2.0.3') 
IGNORE OPTIM EMBEDDED HINTS 


为 了 确保 内 存 中 的 存储 概要 同步 修改 ， 可 以 执行 以 下 PL/SQL 调 用 : 

SQL> execute dbms outln edit.refresh private outline('P OUTLINE EDITING') 

接着 ， 将 初始 化 参数 use_private_outlines 设 置 为 TRUE 或 指定 私有 存储 概要 所 属 的 类 别名 来 激活 
和 测试 私有 存储 概要 。 请 注意 执行 计划 里 的 全 表 扫描 和 Note 部 分 里 的 信息 ， 它 们 都 确认 了 使 用 私有 存 
储 概 要 。 例 如 : 

SQL> ALTER SESSION SET use private outlines = TRUE; 


SQL> EXPLAIN PLAN FOR SELECT * FROM 七 WHERE n = 1970; 


SQL> SELECT * FROM table(dbms xplan.display(NULL,NULL, 'basic +note')); 


| Id | Operation | Name | 


| 0 | SELECT STATEMENT | | 
1 | TABLE ACCESS FULLI T | 


- outline "P OUTLINE EDITING” used for this statement 
一 旦 你 满意 现 有 的 私有 存储 概要 ， 就 可 以 使 用 以 下 SQL 语 句 将 它 当 作 公 共存 储 概要 进行 发 布 : 
SQL> CREATE PUBLIC OUTLINE outline editing FROM PRIVATE p outline editing; 


7. 删除 存储 概要 
使 用 DROP OUTLINE 语 句 或 dbms_outln 包 下 的 drop_by_cat 过 程 ， 可 以 删除 存储 概要 。 前 者 删除 单个 
存储 概要 ， 而 后 者 删除 一 个 类 别 下 的 所 有 存储 概要 : 


DROP OUTLINE outline from text 


execute dbms outln.drop by cat(cat => 'TEST') 
要 删除 私有 存储 概要 ， 必 须 使 用 DROP PRIVATE OUTLINE 语 句 。 


8. 权限 
创建 、 修 改 和 删除 存储 概要 需要 的 系统 权限 分 别 是 create any outline、alter any outline 和 drop 
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any outline。 对 存储 概要 来 说 不 存在 对 象 权限 。 

默认 情况 下 ， 只 有 拥有 dba 或 execute_catalog role 角色 的 用 户 才能 执行 dbms_outln 包 。 相 反 ， 所 
有 用 户 都 可 以 执行 dbms_outln_edit 包 下 的 程序 (已 将 execute 权 限 赋予 public )。 

终端 用 户 不 需要 特定 权限 也 可 以 使 用 存储 概要 。 


提示 “你 永远 不 需要 使 用 outln 账 户 登 录 。 因 此 ， 出 于 安全 考虑 ， 应 该 锁定 该 帐户 或 修改 默认 密码 。 
这 很 重要 ， 因 为 该 帐户 拥有 一 个 非常 危险 的 系统 权限 : execute any procedure。 


11.5.2” 何 时 使 用 


有 了 两 种 情况 需要 考虑 使 用 存储 概要 。 第 一 ， 想 要 优化 一 条 SQL 语句 而 不 能 在 应 用 里 修改 它 时 ( 例 
如 ,无 法 添加 hint )。 第 二 ， 遇 到 任何 原因 导致 的 执行 计划 不 稳定 时 。 由 于 存储 概要 的 目的 是 强制 查询 
优化 器 为 给 定 SQL 语 句 选择 指定 执行 计划 ， 因 此 只 有 当 你 想 明确 限 制 查询 优化 器 选择 单个 执行 计划 时 
才 会 使 用 该 技巧 。 

从 11.1 版 本 之 后 ,存储 概要 不 支持 SQL 计划 管理 。 因 此 , 从 11.1 版 本 起 ， 只 会 在 标准 版 里 使 用 存 
储 概要 。 3 


11.5.3 ”陷阱 和 诬 误 


奇怪 的 是 ,不 能 在 初始 化 文件 ( init.ora 或 spfile.ora ) 中 指定 初始 化 参数 use_stored outlines。 
因此 ， 必 须 在 每 次 实例 启动 后 在 系统 级 别 设置 该 参数 ， 或 每 次 在 会 话 建立 后 在 会 话 级 别 设置 该 参数 。 
这 两 种 情况 都 可 以 通过 数据 库 触 发 器 来 设置 初始 化 参数 。 例 如 ， 下 面 的 触发 器 仅 为 名 称 为 Joze 的 用 户 
设置 初始 化 参数 use_stored_ outlines 

CREATE OR REPLACE TRIGGER enable outlines AFTER LOGON ON joze.SCHEMA 

BEGIN 


EXECUTE IMMEDIATE “ALTER SESSION SET use stored outlines = TRUE'; 
END; 


即使 在 执行 计划 生成 期 间 应 用 了 存储 概要 , 也 并 不 意味 着 查询 优化 器 真正 选择 的 就 是 应 用 期 望 生 
成 的 执行 计划 。 这 个 很 让 人 困惑 。 更 何况 因为 dbms_xplan 包 的 输出 和 v$sql 视 图 的 outline_category 列 
显示 了 解析 阶段 使 用 的 存储 概要 。 下 面 的 例子 ， 是 outline_unreproducible.sql 脚 本 生成 的 输出 节选 : 
SQL> SELECT * FROM t WHERE n = 1970; 


0 | SELECT STATEMENT | | 
1 | TABLE ACCESS BY INDEX ROWID BATCHED| T | 
2 | INDEX RANGE SCAN [1I | 


2 - access("N"=1970) 
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- outline "OUTLINE UNREPRODUCIBLE" used for this statement 
SQL> DROP INDEX ii 


SQL> SELECT * FROM 七 WHERE n = 1970; 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | 
|* 1 | TABLE ACCESS FULL| T | 


- outline "OUTLINE UNREPRODUCIBLE " used for this statement 


存储 概要 最 重要 的 一 个 属性 是 , 它们 是 从 代码 中 分 离 出 来 的 。 不 过 这 也 会 导致 问题 。 实 际 上 ， 由 
于 存储 概要 与 SQL 语 句 之 间 没 有 直接 的 引用 ， 开 发 人 员 完 全 可 以 忽略 存储 概要 的 存在 。 因 此 ， 如 果 开 
发 人 员 修改 了 SQL 语 句 而 导致 它 的 签名 改变 ， 存储 概 要 也 就 跟着 失效 了 。 同 理 ， 当 你 要 部 署 的 应 用 需 
要 使 用 存储 概要 来 保证 正常 运行 时 ， 在 数据 库 安装 期 间 别 忘 了 安装 它们 。 

需要 注意 的 是 ， 当 存储 概要 依赖 的 对 象 被 删除 时 , 存储 概要 不 会 被 删除 。 这 并 不 是 个 问题 。 例 如 ， 
如 果 一 个 表 或 索引 由 于 必须 重组 或 移动 而 需要 重建 ,* 那 么 存储 概要 没有 被 删除 就 是 好 事 ; 否则 还 需要 
重建 它们 。 

两 个 有 相同 文本 的 SQL 语句 拥有 相同 的 签名 。 即 使 它们 引用 的 对 象 在 不 同 的 模式 下 。 这 代表 单个 
存储 概要 可 以 被 两 个 同名 但 处 于 不 同 模式 中 的 表 使 用 。 再 次 强调 ， 你 需要 特别 小 心 , 尤其 是 数据 库 里 
同样 的 对 象 有 多 个 副本 时 。 

当 某 个 SQL 语句 有 存储 概要 ， 同 时 还 有 SQL 配置 文件 和 /或 SQL 计划 基准 ( plan baseline ) 时 ， 查 询 
优化 器 仅 会 使 用 存储 概要 。 当 然 ， 前 提 是 仅 当 存储 概要 的 使 用 处 于 活动 状态 时 。 


11.6 SQL 配置 文件 


你 可 以 将 SQL 优化 委派 给 称 为 自动 调整 优化 器 ( Automatic Tuning Optimizer ) 的 查询 优化 器 的 一 
个 组 件 。 将 此 任务 委派 给 在 第 一 个 位 置 无 法 找到 有 效 执行 计划 的 同一 个 组 件 ， 这 可 能 看 起 来 很 奇怪 
但 实际 上 ， 这 两 种 情况 很 不 同 。 事 实 上 ， 在 正常 情况 下 ， 由 于 查询 优化 器 需要 快速 运转 ( 基本 是 亚 秒 
级 ) 而 被 迫 生成 次 优 的 执行 计划 。 相 反 , 自动 调整 优化 器 会 有 更 多 的 时 间 来 执行 一 个 高 效 的 执行 计划 。 
进一步 讲 ， 它 可 以 使 用 耗 时 技术 ( 如 模拟 分 析 ) 和 加 大 动态 采样 技术 的 使 用 率 来 验证 它 的 估算 。 

自动 调整 优化 器 是 通过 SQL 优化 顾问 (SQL Tuning Advisor ) 引入 的 。 它 的 目的 是 分 析 SQL 语 句 并 
针对 其 性 能 的 提高 提出 建议 ， 包 括 收集 缺失 或 陈旧 的 统计 信息 ， 创 建新 的 索引 ， 修 改 SQL 语 句 或 使 用 
SQL 配置 文件 。 接 下 来 的 部 分 会 专门 介绍 SQL 配置 文件 。 
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关于 SQL 配置 文件 必须 要 知道 的 是 它 只 可 以 通过 SQL 优化 顾问 生成 。 但 在 稍 后 我 会 介绍 ， 你 也 可 
以 手工 创建 它们 。 


11.6.1 工作 原理 


接 下 来 的 几 个 部 分 会 介绍 什么 是 SQL 配置 文件 以 及 如 何 使 用 它们 ， 还 会 提供 关于 它们 的 内 部 工作 
的 信息 。 要 管理 SQL 配置 文件 ， 可 以 使 用 集成 到 企业 管理 器 (Enterprise Manager ) 的 图 形 界 面 。 我 们 
不 会 花 时 间 在 这 上 面 , 因为 在 我 看 来 , 如 果 你 懂得 后 台 发 生 了 什么 , 那么 使 用 图 形 界面 就 不 会 有 问题 。 


1. SQL 配置 文件 的 定义 

SQL 配置 文件 是 一 种 对 象 ， 这 种 对 象 包含 可 帮助 查询 优化 器 为 特定 SQL 语句 找到 高 效 执行 计划 的 
信息 。SQL 配 置 文件 提供 关于 以 下 各 项 的 信息 : 执行 环境 、 对 象 统计 信息 和 与 查询 优化 器 执行 的 评 佑 
相关 的 更 正 。SQL 配 置 文件 的 主要 优势 之 一 是 ， 可 以 影响 查询 优化 器 而 不 用 修改 SQL 语句 或 它 所 在 会 
话 的 执行 环境 。 换 句 话说 ， 它 对 于 连接 到 数据 库 引擎 的 应 用 是 透明 的 。 要 理解 SQL 配置 文件 是 如 何 工 
作 的 ， 让 我 们 来 看 看 它 是 如 何 生 成 和 使 用 的 。 

图 11-4 举 例 说 明 SQL 配置 文件 生成 期 间 的 执行 步 又。 简单 来 说 , 用 户 请 求 SQL 优化 顾问 来 优化 SQL 
语句 ， 然 后 当 SQL 配置 文件 提出 建议 后 ，SQL 优 化 顾问 就 会 接受 。 


SQL 优化 顾问 


本 
提交 SQL 语句 


-4- 
分 析 SQL 语 句 


自动 调整 


查询 优化 器 


二 
获取 统计 信息 
SQL 概要 和 执行 环境 


-D- 
生成 执行 计划 


上 - 
提供 执行 计划 


SQL 引擎 -B- 
优化 SQL 语句 


F 
执行 SQL 语句 
图 11-4 SQL 配置 文件 生成 期 间 执行 的 步骤 


下 面 是 详细 的 步骤 。 
(1) 用 户 将 性 能 糟糕 的 SQL 语句 传递 给 SQL 优化 顾问 。 
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(2) SQL 优化 顾问 要 求 自 动 调整 优化 器 针对 需要 优化 的 SQL 语句 给 出 建议 。 

(3) 查询 优化 器 获取 系统 统计 信息 .与 SQL 语句 引用 的 对 象 相关 的 对 象 统计 信息 以 及 设置 执行 环境 
的 初始 化 参数 。 

(4) 分 析 SQL 语 句 。 在 这 个 过 程 中 , 自动 调整 优化 器 执行 分 析 并 部 分 执行 SQL 语句 来 验证 它 的 猜测 

(5) 自动 调整 优化 器 将 SQL 配置 文件 返回 给 SQL 优化 顾问 。 

(6) 用 户 使 用 SQL 配置 文件 。 

(7) 将 SQL 配置 文件 存储 到 数据 字典 中 。 

图 11-5 举 例 说 明 使 用 SQL 配置 文件 期 间 执行 的 步骤 。 重 点 是 整个 过 程 对 用 户 来 说 是 透明 的 。 


-2- 
给 出 建议 


区 
提交 SQL 语句 SQL 优化 顾问 | 


-6- -4- 
应 用 SQL 概要 分 析 SQL 语 名 


必 - 
获取 统计 信息 
和 执行 环境 


| “自动 调整 
| 优化 器 


查询 优化 器 


-D- 
生成 执行 计划 


-E- 
提供 执行 计划 


SQL 引擎 
优化 SQL 语句 


执行 SQL 语句 


图 11-5 SQL 语句 执行 期 间 执行 的 主要 步 又 


下 面 是 详细 的 步骤 。 

A. 用 户 将 SQL 语句 发 送 给 SQL 引擎 来 执行 。 

B. SQL 引擎 要 求 查询 优化 器 提供 执行 计划 。 

C. 查 询 优化 器 获取 系统 统计 信息 、 与 SQL 语句 引用 的 对 象 相关 的 对 象 统计 信息 、SQL 配 置 文件 以 
及 设置 执行 环境 的 初始 化 参数 。 

D. 查询 优化 器 分 析 SQL 语 句 并 生成 执行 计划 。 

E. 将 执行 计划 传递 给 SQL 引擎 。 

F. SQL 引擎 执行 SQL 语句 。 

下 一 部 分 详细 介绍 SQL 配 置 文件 生成 和 使 用 期 间 执行 的 核心 步骤。 特别 关注 涉及 用 户 的 步骤 。 让 
我 们 先 从 SQL 优 化 顾问 开始 。 
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2. SQL 优化 顾问 

通过 dbms_sqltune 包 可 以 访问 SQL 优化 顾问 的 核心 界面 。 此 外 ， 在 企业 管理 器 中 还 集成 了 一 个 图 
形 界面 。 通 过 这 两 个 界面 可 以 执行 优化 任务 (tuning task )， 还 可 以 查看 产生 的 建议 并 接受 建议 。 在 这 
里 我 并 不 会 向 你 展示 图 形 用 户 界 面 如 何 工作 ， 因 为 更 重要 的 是 要 了 解 后 台 发 生 了 什么 


注意 ”要 使 用 SQL 优化 顾问 和 dbms_sqltune 包 ， 必 须 获 得 使 用 Diagnostics Pack 和 Tuning Pack 的 许可 
记 住 ， 这 些 选 件 仅 在 企业 版 可 用 


要 启动 优化 任务 , 必须 调用 dbms_sqltune 包 中 的 create tuning _ task 函数, 并 将 以 下 各 项 之 一 作为 
-个 参数 传递 ( 函数 会 重 载 四 次 以 接受 不 同类 型 的 参数 )。 
口 SQL 语句 的 文本 。 
口 对 存储 在 库 缓存 中 的 SQL 语句 的 引用 ( sql_id )。 
口 对 存储 在 AWR ( Automatic Workload Repository， 自 动工 作 负 载 存储 库 ) 中 的 SQL 语句 的 引用 
(sql id ) 
口 SQL 优化 集 的 名 称 。 


SQL 优 化 集 (SQL TUNING SETS) 


简单 地 说 ，SQL 优 化 集 是 将 一 组 SQL 语 句 与 其 关联 的 执行 环境 、 执 行 统计 信息 和 可 选 执 行 计划 
存储 到 一 起 的 对 象 ， SQL 优化 集 是 使 用 dbms sqltune 包 来 管理 的 
需要 Tuning Pack 或 Real Application Testing 才 能 使 用 SQL 优化 集 ， 也 就 是 说 要 使 用 企 
可 以 在 Oracle Database Performance Tuning Guide 手 册 (11.2 及 之 后 版 本 ) 或 者 Oracle Database 
SOL Tuning Guide 手 册 ( 12.1 及 之 后 版 本 ) 中 找到 关于 SQL 优化 集 的 更 多 信息 
| 
为 了 通过 将 单个 SQL 语 句 当 作 一 个 参数 来 简化 dbms_sqltune 包 中 的 create tuning _ task 函数 的 执 
行 , 我 编写 了 tune_ last_statement.sql 脚 本 。 其 想法 是 你 执行 希望 已 在 SQL*Plus 中 分 析 过 的 SQL 语 句 ， 
然后 不 使 用 参数 来 调用 该 脚本 。 该 脚本 会 从 v$session 视 图 中 获取 当前 会 话 执 行 的 最 后 一 条 SQL 语 句 的 
引用 ( sql_id ), 然后 创建 并 执行 一 个 引用 该 脚本 的 优化 任务 。 该 脚本 的 核心 部 分 为 以 下 匿名 PL/SQL 块 : 
DECLARE 
1 sql id v$session.prev sql id%TYPE; 
BEGIN 
SELECT prev sql id INTO 1 sql id 
FROM v$session 
WHERE audsid = sys_context('userenv','sessionid'); 


:tuning task := dbms sqltune.create tuning task(sql id => 1 sql id); 
dbms_sqltune.execute tuning task(:tuning task); 
END; 


优化 任务 会 将 多 个 数据 字典 视图 中 的 分 析 输 出 具体 化 。 可 以 使 用 dbms_sqltune 包 中 的 report_ 
tuning_task 抑 数 来 生成 关于 分 析 的 详细 报告 ,而 不 用 直接 查询 视图 。 下 面 的 查询 展示 了 它 的 使 用 , 请 
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注意 需要 使 用 上 一 个 PL/SQL 块 返回 的 优化 任务 名 称 来 引用 优化 任务 : 


SELECT dbms_sqltune.report tuning task(:tuning task) 
FROM dual 


上 个 查询 会 生成 类 似 以 下 的 报告 来 建议 使 用 SQL 配 置 文件 。 请 注意 这 部 分 选 自 profile_opt_ 
estimate.sql 脚 本 生成 的 输出 。 第 一 部 分 显示 分 析 和 SQL 语 句 的 基本 信息 。 第 二 部 分 显示 结果 和 建议 。 
本 例 中 ， 建 议 使 用 SQL 配 置 文 件 。 最 后 一 部 分 显示 应 用 建议 之 前 和 之 后 的 执行 计划 : 

GENERAL INFORMATION SECTION 


Tuning Task Name  : TASK 3401 

Tuning Task Owner : CHRIS 

Workload Type : Single SQL Statement 
Scope : COMPREHENSIVE 

Time Limit(seconds): 42 

Completion Status : COMPLETED 

Started at : 08/02/2013 15:31:44 
Completed at : 08/02/2013 15:31:45 


Schema Name: CHRIS 


SOL ID : bczb6dmm8gcfs 
SOL Text : SELECT * FROM t1, t2 WHERE t14.col1 = 666 AND t1.col2 > 42 AND 
E440 s ty. 


A potentially better execution plan was found for this statement. 


Recommendation (estimated benefit: 65.35%) 


- Consider accepting the recommended SQL profile. 
execute dbms sqltune.accept sql profile(task name => "TASK 3401', 
task owner => 'CHRIS', replace => TRUE); 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time 


0 | SELECT STATEMENT | | 5000 | 9892K| 6210 (1)| 00:01:40 | 
| 1 | NESTED LOOPS | | | | | | 
2 | NESTED LOOPS | | 5000 | 9892K| 6210 (1)| 00:01:40 | 


| TABLE ACCESS BY INDEX ROWID| Ti 

| INDEX RANGE SCAN 
| INDEX UNIQUE SCAN | Tz PK 
| TABLE ACCESS BY INDEX ROWID | T2 


cesal TY . IDs TZ LD" 


2- Using SQL Profile 
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| 9646 | 9542K| 1385 (0)| 00:00:23 | 
| T4 COL1 COL2 I | 9500 | | 27 (0)| 00:00:01 | 
| | | 0 (0)| 00:00:01 | 
| 出 543 | 1 (0)| 00:00:01 | 


access("T1"."COL1"=666 AND "T1"."COL2">42 AND "T1"."COL2" IS NOT NULL) 


| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time 
| 0 | SELECT STATEMENT | | 5000 | 9892K| | 1081 (1)| 00:00:18 | 
|* 1 | HASH JOIN | | 5000 | 9892K| 5008K| 1081 (1)| 00:00:18 | 
| 2| TABLE ACCESS FULL| T2 | 5000 | 4946K| | 174 (0)| 00:00:03 | 
|* 3 | TABLE ACCESS FULL| T1 | 9646 | 9542K| | 344 (0)| 00:00:06 | 
1 = GCESS(" TL" "TD"="T2"." ID") A 
3 - filter("T1"."COL1"=666 AND "T1","COL2">42) 


要 使 用 SQL 优 化 顾问 推荐 的 SQL 配 置 文 件 ， 你 需要 应 用 它 。 下 一 部 分 会 介绍 如 何 应 用 。 无 论 是 否 
应 用 SQL 配置 文件 , 一 旦 不 再 需要 优化 任务 , 就 可 以 调用 dbms_sqltune 包 中 的 drop_tuning_task 过 程 来 


删 掉 它 : 
dbms_sqltune.drop tuning task('TASK 3401'); 


3. 接受 SQL 配置 文件 


dbms_sqltune 包 中 的 accept_sql_profile 过 程 用 来 接受 SQL 优化 顾问 建议 的 SQL 配置 文件 。 它 接受 


以 下 参数 。 


口 Task_name 和 task_owner 参 数 引用 建议 SQL 配置 文件 的 优化 任务 。 
口 Name 和 description 人 参数 指定 SQL 配置 文件 的 名 称 和 描述 。 例 如 ， 使 用 生成 它 的 脚本 名 作为 它 


的 名 小 s 


口 Category 参 数 用 于 将 几 个 SQL 配置 文件 组 合 起 来 ， 以 便于 管理 。 默 认 值 为 DEFAULT。 
口 Replace 参 数 指定 是 否 替 换 已 经 可 用 的 SQL 配置 文件 。 默 认 值 为 FALSE。 
口 Force_match 参 数 指定 如 何 执行 文本 标准 化 。 默 认 值 是 FALSE。 下 一 部 分 会 给 出 更 多 关于 文本 标 


只 有 task_name 是 强制 性 参数 。 例 如 ， 要 应 用 上 面 报告 中 推荐 的 SQL 配置 文件 ， 你 需要 使 用 以 下 


准 化 的 信息 。 
PL/SQL 调 用 : 
dbms_sqltune.accept sql profile(task name => 
task_owner => 
name => 
description => 
category => 


'TASK_3401', 
User, 

‘opt estimate', 
NULL, 

TEST"s 
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force match => TRUE, 
replace => TRUE); 


一 旦 应 用 ，SQL 配 置 文件 就 会 保存 在 数据 字典 中 。dba_sql_profiles 视 图 显示 了 它 的 信息 。 此 外 ， 
从 12.1 版 本 之 后 ，cdb sql_profiles 视 图 也 可 用 。 由 于 SQL 配置 文件 不 会 被 绑 定 到 特定 用 户 ， 因 此 
all sql profiles 和 user sql _profiles 视 图 不 存在 : 


SQL> SELECT category, sql text, force matching 
2 FROM dba sql profiles 
3 WHERE name = 'opt estimate"'; 


CATEGORY SQL TEXT FORCE MATCHING 


TEST SELECT * FROM t1, t2 WHERE t1i.col1 = 666 AND YES 
t1.col2 > 42 AND t1.id = t2.id 


accept_sql profile 函 数 与 accept_sql profile 过 程 一 样 。 叭 一 不 同 的 是 函数 会 返回 SQL 配 秆 文件 
名 。 如 果 没 有 在 输入 函数 中 指定 名 称 而 系统 需要 生成 结果 时 ， 这 会 变 得 很 有 用 。 

4. 修改 SQL 配 置 文件 

创建 SQL 配 置 文件 之 后 ， 可 以 使 用 dbms_sqltune 包 中 的 alter sql_profile 过 程 来 修改 它 的 一 些 属 
性 ， 并 且 还 可 以 使 用 它 来 修改 SQL 配置 文件 的 状态 ( enabled 或 disabled )。 该 过 程 接受 以 下 参数 。 

口 Name 人 参数 指 定 要 修改 的 SQL 配置 文件 。 


口 Attribute_name 参 数 指定 要 修改 的 属性 。 它 能 接受 的 值 有 : name、description、category 和 
status, 


口 Value 参 数 指定 新 的 属性 值 。 | 
这 三 个 参数 是 强制 的 。 例 如 ， 以 下 PL/SQL 调 用 会 禁用 上 面 例子 创建 的 SQL 配 置 文件 : 


dbms_sqltune.alter sql profile(name => "opt_estimate ， 
attribute name => 'status', 
value => 'disabled'); 


5. 文本 标准 化 

SQL 配置 文件 的 一 个 主要 优势 是 尽管 它 应 用 于 某 个 SQL 语句 , 但 它 并 不 会 对 SQL 语句 做 任何 修改 
实际 上 上 ，SQL 配 置 文件 保存 在 数据 字典 中 ,并 且 查 询 优 化 器 会 自动 选择 它们 。 图 11-6 显 示 了 在 选择 过 
程 中 会 实施 的 基本 步 又。 首先 , 会 使 SQL 语句 标准 化 , 这 代表 不 仅 要 不 区 分 大 小 写 , 还 要 不 使 用 空格 。 
基于 结果 的 SQL 语句 会 计算 出 签名 。 然 后 会 根据 签名 在 数据 字典 中 进行 查找 。 每 当 找到 有 相同 签名 的 
SQL 配置 文件 时 ， 就 会 执行 检查 来 确保 SQL 语句 是 最 优 的 并 且 关 联 SQL 配 置 文件 的 SQL 语句 也 是 等 价 
的 。 这 一 步 很 重要 ， 因 为 签名 其 实 是 个 散 列 值 ， 因 此 可 能 会 存在 冲突 。 如 果 检 测 成 功 ， 会 将 与 SQL 配 
置 文件 关联 的 hint 加 入 到 生成 的 执行 计划 中 。 

如 果 SQL 语 句 包含 的 文字 发 生 改 变 ， 它 会 像 散 列 值 签 名 一 样 改变 。 因 此 ，SQL 配 置 文件 是 没 用 
的 ， 因 为 SQL 配置 文件 被 绑 定 到 某 个 仅 会 执行 一 次 的 SQL 语句 。 为 了 避免 这 个 问题 ， 数 据 库 引 称 会 
在 标准 化 阶段 去 除 文字 部 分 。 要 启用 这 个 功能 ,需要 在 应 用 SQL 配置 文件 时 将 force_match 参 数 设置 
为 TRUE 。 
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基于 SQL 语句 签名 
查找 存储 概要 


包含 存储 概要 HINT 


” 洽 成 执行 计划 


图 11-6 SQL 配置 文件 选择 期 间 实 施 的 主要 步骤 


为 了 研究 文本 标准 化 的 工作 原理 , 可 以 使 用 dbms_sqltune 包 中 的 sqltext to_signature 函 数 。 它 需 
要 两 个 输入 参数 ，sql_text 和 force_match。 前 者 指定 SQL 语句 ， 后 者 指定 文本 标准 化 的 类 型 。 下 面 是 
节选 自 profile_signature.sql 脚 本 生成 的 输出 , 展示 了 在 签名 不 同 但 是 相似 的 SQL 语句 上 force_match 
参数 的 影响 

口 force_ match 设 置 为 FALSE: 空格 和 不 区 分 大 小 写 


SOL TEXT SIGNATURE 

SELECT * FROM dual WHERE dummy = “X" 7181225531830258335 
select * from dual where dummy="'X' 7181225531830258335 
SELECT * FROM dual WHERE dummy = 'x’ 18443846411346672783 


* 

SELECT * FROM dual WHERE dummy = "Y" 909903071561515954 
SELECT * FROM dual WHERE dummy = 'X' OR dummy = :bl 14508885911807130242 
SELECT * FROM dual WHERE dummy = 'Y' OR dummy = :bl 816238779370039768 


口 force_match 设 置 为 TRUE: 空格 和 不 区 分 大 小 写 和 文字 。 然 而 ， 如 果 SQL 语 句 中 使 用 了 绑 定 变 
量 ， 那 么 不 会 执行 文字 替换 。 


上 


SQL_TEXT SIONATURE 
SELECT * FROM dual WHERE dummy = “X" 10668153635715970930 
select * from dual Where dummy="X"' 10668153635715970930 
SELECT * FROM dual WHERE dummy = 'x' 10668153635715970930 


SELECT * FROM dual WHERE dummy = "YY" 10668153635715970930 


352 第 11 章 ”SQL 优化 技巧 


SELECT * FROM dual WHERE dummy = 'X' OR dummy = :b1 14508885911807130242 
SELECT * FROM dual WHERE dummy = 'Y' OR dummy = :bl 816238779370039768 


请 注意 , 同一 SQL 语句 可 以 有 两 个 SQL 配置 文件 : 一 个 使 用 设置 为 FALSE 的 force_match 参 数 , 另 一 
个 使 用 设置 为 TRUE 的 force_match 参 数 。 如 果 两 个 SQL 配置 文件 都 存在 ， 那 么 使 用 设置 为 FALSE 的 
force_match 参 数 的 SQL 配置 文件 会 优先 于 设置 为 TRUE 的 。 这 是 因为 设置 为 FALSE 的 force_match 参 数 会 
比 另 一 个 更 详细 些 。 这 表示 可 以 使 用 一 个 SQL 配置 文件 来 对 应 大 多 数 文字 ， 而 另 一 个 来 对 应 需要 特别 
处 理 的 ( 比如 ， 当 对 文字 的 限制 应 用 在 一 个 数据 倾斜 的 列 上 时 )。 


6. 激活 SQL 配 置 文件 

可 以 在 系统 或 会 话 级 别 通过 初始 化 参数 sqltune_category 来 控制 SQL 配置 文件 的 激活 。 默 认 值 为 
DEFAULT。 这 也 是 dbms sqltune 包 中 的 accept_sql_profile 过 程 中 category 参 数 的 默认 值 。 因此 ,如 果 应 
用 SQL 配置 文件 时 未 指定 类 别 ， 那 么 会 激活 默认 的 SQL 配置 文件 。 应 用 SQL 配置 文件 时 ， 会 把 类 别名 
当 作 一 个 值 来 处 理 。 比 如 ， 下 面 的 SQL 语句 在 会 话 级 别 激 活 属于 test 类 别 的 SQL 配置 文件 ; 

ALTER SESSION SET sqltune category = test 

这 个 初始 化 参数 只 支持 单个 类 别 。 很 显然 在 给 定时 间 内 一 个 会 话 只 能 激活 一 个 类 别 。 

为 了 查 明 查 询 优化 器 是 否 使 用 了 SQL 配 置 文件 ， 可 以 利用 doms_xplan 包 中 的 函数 。 正 如 下 面 的 例 
子 ， 它 们 输出 的 Note 部 分 明确 给 出 了 需要 的 信息 : 

SOL> EXPLAIN PLAN FOR SELECT * FROM t ORDER BY id; 


SQL> SELECT * FROM table(dbms xplan.display); 


0 | SELECT STATEMENT | | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 
2 | INDEX FULL SCAN | TPK | 


- SQL profile "import sql profile" used for this statement 
对 于 保存 在 库 缓存 中 的 游标 ，v$sql 视 图 的 sql_profile 列 显示 了 在 游标 执行 计划 生成 期 间 使 用 的 
SQL 配置 文件 名 。 当 没有 使 用 SQL 配置 文件 时 ， 该 列 值 为 NULL。 


7. 移动 SQL 配置 文件 

dbms_sqltune 包 提供 了 多 个 过 程 以 在 数据 库 之 间 移 动 SQL 配置 文件 。 如 图 11-7 显 示 , 会 提供 以 下 功能 
口 可 以 通过 create _stgtab sqlprof 过 程 创建 临时 表 。 

口 可 以 通过 pack_stgtab_sqlprof 过 程 将 数据 字典 中 的 SQL 配置 文件 复制 到 临时 表 中 。 

口 可 以 通过 remap_stgtab_sqlprof 过 程 修改 保存 在 临时 表 中 的 SQL 配置 文件 名 和 类 别 。 

口 可 以 通过 unpack_stgtab_sqlprof 过 程 将 临时 表 中 的 SQL 配置 文件 复制 到 数据 字典 中 。 
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图 11-7 使 用 dbms_sqltune 包 移动 SQL 配 置 文件 


请 注意 ， 在 数据 库 之 间 移 动 临时 表 依 靠 的 是 数据 移动 技术 ( 例如 ， 数 据 泵 ( Data Pump ) 或 旧 有 
的 导出 ( export ) 和 导入 ( import ) 程序 )， 并 不 依靠 dbms_sqltune 包 本 身 。 

下 面 的 例子 ， 引 用 自 profile cloning.sql 脚 本 ， 显 示 了 如 何在 单个 数据 库 中 复制 SQL 配置 文件 。 
首先 ，mystgtab 临 时 表 是 在 当前 模式 ( schema ) 中 创建 的 : 

dbms_sqltune.create stgtab sqlprof(table name => 'MYSTGTAB', 


schema_name => User, 
tablespace name => 'USERS'); 


接着 ， 会 将 名 称 为 opt_estimate 的 SQL 配置 文件 从 数据 字典 复制 到 临时 表 中 : 
dbms sqltune.pack stgtab sqlprof(profile name => 'opt estimate', 
profile category => “TEST ， 


staging table name => 'MYSTGTAB', 
staging_ schema owner => user); 


将 SQL 配置 文件 复制 回 数 据 字 典 中 之 前 ， 必 须 修改 SQL 配置 文件 名 。 同 时 ， 也 要 修改 它 的 类 别 : 


dbms_sqltune.remap stgtab sqlprof(old profile name => 'opt estimate', 
new_ profile name => "opt_estimate clone', 
new profile category => 'TEST _ CLONE', 
staging table name => 'MYSTGTAB', 
staging schema owner => user); 


最 后 ， 将 SQL 配置 文件 从 临时 表 复制 到 数据 字典 中 。 由 于 参数 会 被 替换 成 TAUE， 同 名 的 SQL 配置 
文件 也 会 被 改写 : 


dbms_sqltune.unpack stgtab sqlprof(profile name => 'Opt estimate clone', 
profile category => 'TEST_CLONE', 
replace => TRUE, 


staging table name => 'MYSTCTAB', 
staging schema_ owner => user); 


8. 删除 SQL 配置 文件 
可 以 使 用 dbms_sqltune 包 中 的 drop_sql_profile 过 程 来 删除 数据 字典 中 的 SQL 配置 文件 。Name 人 参数 
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指定 SQL 配置 文件 名 。Ignore 参 数 指定 当 SQL 配 置 文件 不 存在 时 是 否 报错 。 默 认 值 为 FALSE: 


dbms_sqltune.drop sql profile(name => "opt_estimate '， 
ignore => TRUE); 


9. 权限 

要 创建 、 修 改 和 删除 SQL 配 置 文 件 ， 分 别 需 要 create any sql profile、alter any sql profile 和 
drop any sql profile 系 统 权 限 。 然 而 ， 从 11.1 版 本 开始 ， 这 三 个 系统 权限 不 再 支持 administer sql 
management 系 统 权 限 对 象 SQL 配置 文件 没有 对 象 权 限 。 要 使 用 SQL 优化 顾问 , 就 需要 advisor 系 统 权限 

最 终 用 户 不 需要 特定 权限 也 可 以 使 用 SQL 配置 文件 。 


10. 未 公开 特性 

SQL 配置 文件 如 何 影响 查询 优化 器 ? Oracle 并 未 在 其 文档 中 给 出 答案 。 我 认为 高 效 地 使 用 特性 的 
最 好 方法 就 是 了 解 它 的 工作 原理 。 因 此 ， 让 我 们 来 看 看 它 的 内 部 。 简 单 地 说 ，SQL 配 置 文件 保存 了 一 
组 hint 来 表示 查询 优化 器 执行 的 优化 。 其 中 一 些 hint 是 在 文档 里 有 记录 的 ,并且 也 用 于 其 他 环境 。 其 他 
hint 是 未 公开 的 ， 并 且 通 常 只 会 由 SQL 配置 文件 使 用 。 换 句 话说， 它们 都 为 了 这 个 目的 而 使 用 。 它 们 
全 部 都 是 普通 的 hint， 因 此 也 可 以 直接 加 入 到 SQL 语句 中 。 

在 讨论 如 何 查询 与 SQL 配置 文件 关联 的 hint 列 表 前 ， 让 我 们 先 引入 一 个 基于 profile all rows.sql 
脚本 的 例子 。 它 的 目的 是 为 了 展示 ， 使 用 SQL 配置 文件 是 可 以 命令 查询 优化 器 改变 优化 模式 的 。 在 这 
个 特定 的 例子 中 ， 需 要 改变 优化 器 模式 ， 是 因为 查询 包含 了 rule hint， 这 会 强制 查询 优化 器 在 基于 规 
则 的 模式 下 工作 。 查 询 和 它 的 执行 计划 如 下 : 

SQL> SELECT /*+ rule */ * FROM 七 ORDER BY id; 


0 | SELECT STATEMENT | | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 
2 | INDEX FULL SCAN | TPK | 


- rule based optimizer used (consider using cbo) 
在 让 SQL 优 化 顾问 在 查询 上 工作 并 且 应 用 SQL 配 置 文件 后 ， 执 行 计划 也 会 改变 。 正 如 Note 部 分 指 
出 的 那样 ， 会 在 执行 计划 生成 期 间 使 用 SQL 配置 文件 : 
SOL> SELECT /*+ rule */ * FROM t ORDER BY id; 


| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time 

| 0 | SELECT STATEMENT | | 10000 | 1015K| | 277 (1)| 00:00:04 | 
| 1| SORT ORDER BY | | 10000 | 1015K| 1120K| 277 (1)| 00:00:04 | 
| 2| TABLE ACCESS FULL| T | 10000 | 1015K| | 38 (0)| 00:00:01 | 
Note 


- SQL profile "all rows" used for this statement 
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不 幸 的 是 ， 与 SQL 配置 文件 关联 的 hint 无 法 通过 数据 字典 视图 显示 。 实 际 上 ， 只 有 两 个 视图 能 提 
供 关 于 SQL 配置 文件 的 信息 : dba_sql_profiles 视 图 和 在 12.1 多 租户 环境 下 的 cdb_sql_profiles 视 图 ， 
它们 提供 除了 hint 以 外 的 所 有 信息 。 如 果 想 知道 哪些 hint 被 用 于 SQL 配 置 文 件 ,那么 你 有 两 个 选择 。 第 
一 个 是 直接 查询 内 部 数据 字典 表 ,下 面 的 查询 会 介绍 针对 由 profile_all_rows.sql 脚 本 生成 的 SQL 配 置 
文件 该 如 何 查询 。 请 注意 ， 会 用 到 两 个 初始 化 参数 hint ( all_rows 和 optimizer features_enable )。 此 外 ， 
要 命令 查询 优化 器 忽略 当前 SQL 语句 中 的 hint ( 本 例 是 rule hint )， 会 用 到 ignore optim_embedded hints。 
口 该 查询 在 10.2 版 本 中 可 用 : 


SQL> SELECT attr val 
2 FROM sys.sqlprof$ p, sys.sqlprof$attr a 
3 WHERE p.sp name = "all rows' 
4 AND p.signature = a.signature 
5 AND p.category = a.category; 


ALL_ROWS 
OPTIMIZER_FEATURES ENABLE(default) 
IGNORE_OPTIM_ EMBEDDED_HINTS 


口 该 查询 在 11.1 版 本 中 可 用 : 2 


SQL> SELECT extractValue(value(h),'.') AS hint 
2 FROM sys.sqlobj$data od, sys.sqlobj$ so, 
table(xmlsequence(extract(xmltype(od.comp data),'/outline data/hint'))) h 
WHERE so.name = 'all rows' 
AND so.signature = od.signature 
AND so.category = od.category 
AND so.obj type = od.obj type 
AND so.plan id = od.plan id; 


co ~ 上 三山 


ALL_ROWS 
OPTIMIZER_FEATURES_ENABLE(default) 
IGNORE OPTIM_EMBEDDED_HINTS 


第 二 种 可 能 是 将 SQL 配置 文件 移动 到 临时 表 中 ， 这 在 “移动 SQL 配置 文件 ”部 分 介绍 过 。 接 着 ， 
使 用 类 似 以 下 的 查询 , 可 以 从 临时 表 中 获取 hint。 请 注意 会 执行 通过 table 范 数 的 非 峙 套 查询 , 因为 hint 
存储 在 VARCHAR2 变 长 数组 中 : 
SQL> SELECT * 
2 FROM table(SELECT attributes 


3 FROM mystgtab 
4 WHERE profile name = 'opt estimate'); 


COLUMN_VALUE 
ALL_ROWS 

OPTIMIZER_FEATURES ENABLE(default) 
IGNORE_OPTIM EMBEDDED_HINTS 
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SQL 配置 文件 不 仅 可 以 更 改 优化 器 的 模式 ， 实 际 上 ， 它 还 可 以 用 来 校正 查询 优化 器 执行 错误 的 
基数 估算 。Profile_opt_estimate.sql 脚 本 展示 的 就 是 这 样 的 例子 。 使 用 第 10 章 介绍 的 技巧 可 以 识 
别 错误 的 估算 。 可 以 看 到 在 下 面 的 例子 中 ， 几 项 操作 的 估算 基数 ( E-Rows ) 与 真实 基数 ( A-Rows ) 
完全 不 同 : 


| Id | Operation | Name Starts | E-Rows | A-Rows 
| 0 | SELECT STATEMENT | | | 4750 
| 1 | NESTED LOOPS | 1 | | 4750 
| 2| NESTED LOOPS | 1 | 20 | 4750 
| 3| TABLE ACCESS BY INDEX ROWID| T1 1 | 20 | 9500 
|* 4| INDEX RANGE SCAN | T1 COL1 COL2 I | 20 | 9500 
|* 5| INDEX UNIOUE SCAN | T2_PK 9500 | 1 | 4750 
| 61| TABLE ACCESS BY INDEX RONID | T2 4750 | 1 | 4750 


如 果 使 用 SQL 优化 顾问 来 分 析 这 样 的 案例 并 且 应 用 它 的 建议 , 就 像 profile opt_estimate.sq]l 脚 本 
那样 ， 那 么 会 创建 包含 以 下 hint 的 SQL 配置 文件 : 

OPT_ESTIMATE(@"SEL$1", INDEX SCAN, "T1"@"SEL$1", "T1 COL1 COL2 I", SCALE ROWS=477.9096254) 

OPT_ESTIMATE(@"SEL$1", NL] INDEX SCAN, "T2"@"SEL$1", ("T1"@"SEL$1"), "T2_PK", 
SCALE_ROWS=0.4814075109) 

OPT_ESTIMATE(@"SEL$1", NL] INDEX FILTER, "T2"@"SEL$1", ("T1"@"SEL$1"), "T2_ PK", 
SCALE_ ROWS=0.4814075109) 

OPT_ESTIMATE(@"SEL$1", TABLE, "T1"@"SEL$1", SCALE ROWS=486.2776343) 

OPTIMIZER_FEATURES ENABLE(default) 


需要 额外 注意 的 是 未 公开 的 hint opt_estimate ,使 用 这 个 特别 的 hint， 就 可 以 通知 查询 优化 器 它 的 
一 些 估算 是 错误 的 并 且 还 可 以 得 知 错误 程度 。 例 如 ， 第 一 个 hint 告 诉 查 询 优化 器 对 访问 表 t1 的 操作 佑 
算 按 比例 增加 大 约 478 倍 (“ 大 约 ” 是 因为 9500/20 的 分 母 在 dbms_xplan 的 输出 中 被 四 舍 五 人 了 )。 

适当 地 使 用 SQL 配置 文件 ， 估 算 会 变 得 更 精确 。 同 样 请 注意 查询 优化 器 选择 了 另 一 个 执行 计划 ， 
它 是 最 初 用 来 创建 SQL 配置 文件 的 : 


| Id | 0peration | Name | Starts | E-Rows | A-Rows | 
| 0 | SELECT STATEMENT | | | | 4750 | 
|* 1 | HASH JOIN | | 1| 5000 | 4750 | 
| 2| TABLE ACCESS FULL| T2 | 1| 5000 | 5000 | 
|* 3 | TABLE ACCESS FULL| T1 | 1| 9666 | 9500 | 


男 一 个 SQL 配 置 文件 的 用 处 是 当 对 象 存在 错误 或 丢失 对 象 统计 信息 时 。 当 然 这 不 应 该 发 生 , 但 当 
它 发 生 并 且 动 态 采样 无 法 为 查询 优化 器 提供 需要 的 信息 时 ,就 可 以 使 用 SQL 配 置 文件 。 
Profile object_stats.sql 脚 本 提供 了 这 样 的 例子 。 脚 本 生成 的 SQL 配 置 文件 是 由 hint 组 成 的 ， 尤 其 是 
以 下 这 些 。 正 如 hint 名 显示 的 那样 ， 每 个 hint 都 在 为 表 、 对 象 或 列 提供 对 象 统计 信息 : 


TABLE STATS("CHRIS"."T2", scale, blocks=735 rows=5000) 
INDEX_STATS("CHRIS"."T2", "T2 PK", scale, blocks=14 index rows=5000) 
COLUMN_STATS("CHRIS"."T2", "PAD", scale, length=1000) 
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COLUMN_STATS("CHRIS"."T2", "COL2", scale, length=3) 
COLUMN_STATS("CHRIS"."T2", "GOL1” ; Seale, length=3) 
COLUMN_STATS("CHRIS"."T2", "ID", scale, length=3 distinct=5000 nulls=0 min=2 max=10000) 


对 于 这 部 分 关于 未 公开 特性 的 内 容 ， 我 最 后 想 介绍 的 是 手工 创建 SQL 配置 文件 。 换 句 话 说， 代替 
询问 SQL 优化 顾问 分 析 并 应 用 SQL 配置 文件 , 你 可 以 建立 自己 的 SQL 配置 文件 。 通 过 调用 dbms_sqltune 
包 中 的 import_sql profile 过 程 来 手工 创建 SQL 配 置 文件 。 下面 的 示例 是 基于 profile import.sql 脚 本 
的 调用 。Sql_text 参 数 指定 了 绑 定 SQL 配 置 文件 的 SQL 语句 ，profile 参 数 指定 hint 列 表 。 其 他 参数 与 
之 前 介绍 的 accept_sql_profile 过 程 的 参数 具有 相同 的 定义 : 

dbms_ sqltune.import sql profile( 
name => "import sql profile', 
description => 'SQL profile created manually’, 
category => 'TEST', 
sql text => "SELECT * FROM 七 ORDER BY id', 
profile => sqlprof attr('first rows(42)','optimizer features enable(default)'), 
replace => FALSE, 
force match => FALSE 
); 


注意 尽管 dbms sqltune 包 中 的 import sql pro 全 le 并 不 是 官方 记录 的 , 但 创建 SQL 配 置 文件 的 方法 ， 
与 应 用 SQL 优化 顾问 的 建议 而 由 数据 库 引 擎 创建 的 SQL 配置 文件 是 一 样 的 。 因 此 ， 我 认为 使 用 
import sql_profile 过 程 没 问题 。 此 外 ， 在 Oracle Suport 说 明 SOLT (SOLTXPLAIN) - Tool that 
helps to diagnose a SOL statement performing poorly or one that produces wrong results (215187.1) 
中 的 coe_xfr_sql_profile.sql 脚 本 使 用 了 同样 的 过 程 来 创建 SQL 配 置 文件 。 另 外 ， 可 以 执行 
coe_xfr_sql_profile.sql 脚 本 来 为 库 缓存 中 缓存 的 或 AWR 中 存储 的 游标 创建 SQL 配置 文件 。 


11.6.2” 何 时 使 用 


每 当 要 优化 一 条 特定 的 SQL 语句 并 且 无 法 在 应 用 中 更 改 它 〈 例 如， 无 法 添加 hint ) 时 ， 都 应 该 
考虑 使 用 SQL 配置 文件 。 请 记 住 ，SQL 配 置 文件 的 目的 是 为 查询 优化 器 提供 关于 要 处 理 的 数据 以 及 
关于 执行 环境 的 附加 信息 。 因 此 ， 不 要 在 需要 为 某 条 特定 SQL 语句 强制 使 用 某 个 特定 执行 计划 时 使 
用 该 技术 。 

为 此 , 应 该 使 用 存储 概要 或 SQL 计划 管理 。 唯 一 的 例外 是 当 你 想 要 利用 与 force_match 参 数 相 关 的 
文本 标准 化 功能 时 。 实 际 上 ， 存 储 概要 和 SQL 计划 管理 都 不 提供 类 似 的 功能 。 

将 初始 化 参数 control management _pack_access 设 置 为 none 或 diagnostic 时 ， 将 无 法 使 用 SQL 优化 
顾问 。 如 果 尝 试 去 使 用 , 那么 数据 库 引 擎 会 引发 ORA-13717: Tuning Package License is needed for using 
this feature 错 误 。 此 外 ， 查 询 优化 器 会 包 略 现 有 SQL 配置 文件 。 


11.6.3 ”陷阱 和 请 误 


SQL 配置 文件 最 重要 的 属性 之 一 是 ， 它 们 与 代码 是 分 开 的 。 然 而 这 也 会 带 来 问题 。 实 际 上 ， 由 于 
在 SQL 配置 文件 与 SQL 语句 之 间 没 有 直接 的 关联 ， 开 发 人 员 很 可 能 会 彻底 忽略 SQL 配置 文件 的 存在 。 


358 第 11 章 SQL 优化 技巧 


结果 ， 如 果 开发 人 员 修 改 SQL 语 句 将 会 导致 它 的 签名 发 生 改变 ， 这 样 SQL 配 置 文件 就 不 会 再 生效 了 
同样 ， 当 你 部 署 一 个 应 用 需要 依靠 SQL 配置 文件 来 保证 它 执 行 正 确 时 ， 必 须 记 得 在 数据 库 设 置 期 间 安 
装 它们 。 

如 果 需 要 生成 SQL 配置 文件 ， 最 好 的 做 法 是 在 生产 环境 中 生成 ( 如 果 可 行 )， 然 后 移动 到 其 他 环 
境 中 去 做 测试 。 但是， 问题 是 在 移动 SQL 配置 文件 之 前 ， 你 不 得 不 应 用 它 。 你 不 会 想 在 未 测试 之 前 就 
在 生产 环境 中 应 用 它 ， 因 此 需要 确保 应 用 的 SQL 配置 文件 使 用 的 类 别 与 初始 化 参数 sqltune category 
激活 的 类 别 不 同 。 那样 , SQL 配置 文件 就 不 会 在 生产 数据 库 上 使 用 。 总 之 , 你 总 是 可 以 在 过 后 修改 SQL 
配置 文件 的 类 别 。 

需要 注意 的 是 ，SQL 配 置 文件 依赖 的 对 象 被 删除 时 ，SQL 配 置 文件 并 不 会 被 删除 。 但 这 并 不 是 问 
题 。 例 如 ， 如 果 一 个 表 或 索引 因为 它 必 须 重 组 或 移动 而 需要 重建 ， 那 么 SQL 配置 文件 没 被 删除 就 是 好 
事 。 和 否则 ， 就 有 必要 重建 它们 。 

两 个 有 相同 文本 的 SQL 语句 拥有 相同 的 签名 。 即 使 它们 引用 的 对 象 在 不 同 的 用 户 下 。 这 代表 单个 
存储 概要 可 以 被 两 个 同名 但 是 不 同 用 户 的 表 使 用 。 再 次 强调 ， 你 需要 小 心 , 尤其 是 当 数 据 库 中 同样 的 
对 象 有 多 个 副本 时 。 

在 11.2.0.2 及 之 前 的 版 本 中 ， 因 为 Oracle Support 文 档 8SOL profile not used in the Active Physical 
Standby( 10050057.8 ) 中 描述 的 bug， 导 致 SQL 配置 文件 在 Active Data Guard 环 境 下 受 限 。 你 可 以 在 主 
实例 上 使 用 SQL 配置 文件 ， 但 并 不 总 是 能 在 备用 实例 上 使 用 。 

当 SQL 语句 有 SQL 配置 文件 和 存储 概要 时 ， 查 询 优化 器 会 仅 使 用 存储 概要 。 当 然 ， 前 提 是 存储 概 

当 SQL 语 名 有 SQL 配置 文件 和 SQL 计划 基线 时 , 查询 优化 器 会 尝试 合并 与 SQL 配置 文件 关联 的 hint 
和 与 SQL 计划 基线 关联 的 hint。 然 而 , 合并 SQL 配置 文件 与 SQL 计划 基线 有 使 用 限制 。 实 际 上 ， 就 像 下 
一 部 分 介绍 的 那样 ，SQL 计 划 基 线 的 目的 是 强制 使 用 特定 的 执行 计划 。 结 果 ， 在 考虑 使 用 SQL 计划 基 
线 之 前 ，SQL 配 置 文件 的 用 处 或 许 只 是 生成 新 的 不 被 应 用 的 执行 计划 。 
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从 11.1 版 本 开始 ，SQL 计 划 管 理 (SPM ) 取代 了 存储 概要 。 其 实 ， 可 以 将 SQL 计划 管理 看 作 是 存 
储 概要 的 增强 版 。 实际 上 , 它们 之 间 不 仅 具有 相同 的 特性 , 并 且 SQL 计 划 管 理 也 具有 同样 的 设计 目的 ， 
即使 执行 环境 或 对 象 统计 信息 发 生 改 变 ， 也 可 以 提供 稳定 的 执行 计划 。 此 外 ， 与 存储 概要 一 样 ，SQL 
计划 管理 也 可 以 在 不 修改 应 用 的 情况 下 对 应 用 进行 优化 。 


警告 ”Oracle 文档 中 唯一 提 到 的 SQL 计划 管理 的 用 法 是 稳定 执行 计划 。 并 未 提 及 在 不 修改 提交 SQL 语 
多 的 应 用 的 情况 下 使 用 SQL 计划 管理 来 改变 当前 的 执行 计划 ( 与 某 个 给 定 的 SQL 语 铅 相关 )， 
出 于 某 些 原因 ， 我 也 选择 忽略 该 功能 。 


下 面 是 SQL 计划 管理 包含 的 关键 元 素 。 
口 SQL 计划 基线 : 用 来 稳定 执行 计划 的 实际 对 象 。 
口 语句 日 志 : 之 前 执行 过 的 SQL 语句 列表 。 
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口 SQL 管理 基础 (SMB ): 存储 SQL 计划 基线 和 语句 日 志 的 位 置 。 需 要 的 空间 是 在 sysaux 表 空间 
中 分 配 的 。 


11.7.1 工作 原理 


接 下 来 的 几 个 部 分 会 介绍 SQL 计划 管理 是 如 何 工作 的 。 包 括 什么 是 SQL 计划 基线 以 及 如 何 管理 它 
们 。 要 管理 SQL 计划 基线 ， 可 以 使 用 集成 到 企业 管理 器 的 图 形 界 面 。 我 们 不 会 介绍 这 部 分 内 容 ， 因 为 
在 我 看 来 ， 如 果 你 懂得 后 台 发 生 了 什么 ,那么 使 用 图 形 界 面 就 不 会 有 问题 。 


1. 什么 是 SQL 计划 基线 

SQL 计划 基线 是 用 来 影响 查询 优化 器 生成 执行 计划 的 对 象 。 更 具体 一 点 ，SQL 基 线 包含 了 一 个 或 
多 个 执行 计划 ,而 执行 计划 里 包含 一 组 hint。 基本 上 ，SQL 计 划 基 线 用 于 强迫 查询 优化 需 针 对 给 定 SQL 
语句 生成 特定 的 执行 计划 。 


告 并 不 是 所 有 的 hint 都 会 存储 在 SQL 计划 基线 中 。 可 以 执行 下 面 的 查询 来 查 明 不 会 存储 哪些 hint: 
SELECT name FROM v$sql hint WHERE version outline IS NULL 


即使 大 多 数 hint 无 法 保存 在 SQL 计划 基线 中 也 不 会 影响 到 执行 计划 ( 例如 ，gather plan_ 
statistics )， 但 其 中 一 些 会 影响 (例如 ，materialize 和 inline )。 因 此 ， 对 于 有 些 执行 计划 ， 
如 果 不 增加 hint， 在 SQL 语 句 中 是 无 法 通过 SQL 计 划 基 线 来 强制 修改 的 


SQL 计 划 基 线 的 其 中 一 个 优势 它 适用 于 某 个 特定 SQL 语 句 ， 并 且 不 需要 修改 SQL 语 句 本 身 。 实 际 
上 ，SQL 计 划 基 线 存 储 在 SQL 基础 管理 平台 上 ， 并 且 查 询 优 化 器 会 月 动 选择 它们 。 图 11-8 显 示 了 选择 
期 间 执行 的 基本 步骤 。 

(1) 首先 , SQL 语句 按照 正常 方法 解析 。 换 名 话说 , 查询 优化 器 不 使 用 SQL 计划 基线 生成 执行 计划 。 

(2) 接 着 , 查询 优化 器 会 将 SQL 语句 标准 化 , 使 其 不 区 分 大 小 写 并 且 与 文本 中 的 空格 无 关 。 计 算出 
产生 的 SQL 语句 的 签名 ， 然 后 在 SQL 基础 管理 平台 中 执行 查找 。 

如 果 找 到 相同 签名 的 SQL 计划 基线 ， 就 会 执行 检查 来 确保 SQL 语句 是 最 优 的 ， 并 且 与 关联 SQL 计 
划 基 线 的 SQL 语句 是 等 价 的 。 这 一 步 是 必要 的 检查 ， 因 为 签名 是 散 列 值 ， 因 此 可 能 存在 冲突 。 

(3) 检查 成 功 后 ， 查 询 优化 器 会 核实 SQL 计划 基线 是 和 否 包 含 没 有 使 用 SQL 计划 基线 生成 的 执行 计 
划 。 如 果 包 含 它 并 且 接受 (信任 ) 它 ， 就 会 执行 它 . 

(4) 如 果 将 另外 一 个 接受 的 执行 计划 存储 在 SQL 计划 基线 中 ,那么 与 它 相关 的 hint 会 用 来 生成 另 一 
个 执行 计划 , 请 注意 如 果 SQL 计 划 基 线 包含 多 个 接受 的 执行 计划 , 查询 优化 器 会 选择 代价 最 小 的 那个 。 

(5) 最 后 , 查询 优化 器 检查 利用 SQL 计划 基线 生成 的 执行 计划 是 否 会 重 现 预 估 的 执行 计划 。 只 有 最 
后 这 个 检查 满足 条 件 时 ， 执 行 计划 才 可 用 。 如 果 这 个 检查 通 不 过 ， 查 询 优化 器 会 尝试 其 他 接受 的 执行 
计划 ， 如 果 所 有 的 执行 计划 都 无 法 重 现 ， 它 会 选择 没有 使 用 SQL 计 划 基 线 生 成 的 执行 计划 。 
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不 使 用 基线 
生成 执行 计划 


根据 SQL 语 名 
签名 寻找 基线 


使 用 基线 HINT 
生成 执行 计划 


月 


丰 
不 使 用 基线 使 用 基线 运行 
运行 执行 计划 执行 计划 


图 11-8 SQL 计划 基线 选择 期 间 执行 的 主要 步 又 


2. 捕获 SQL 计划 基线 
可 以 通过 几 个 步骤 来 捕获 新 的 SQL 计划 基线 。 基 本 上 ， 它 们 是 由 数据 库 引擎 自动 创建 的 ， 或 由 数 
据 库 管 理 员 或 开发 人 员 手 动 创建 。 下 面 三 部 分 分 别 介绍 了 三 种 方法 。 


@ 自动 捕获 

将 初始 化 参数 optimizer capture sql_ plan_baselines 设 置 为 TRUE 时 ， 查 询 优化 器 会 自动 保存 新 的 
SQL 计划 基线 。 默 认 情 况 下 ， 会 将 初始 化 参数 设置 为 FALSE。 可 以 在 会 话 和 系统 级 别 更 改 它 。 

启用 自动 捕获 时 ， 查 询 优化 会 为 每 条 多 次 执行 〈( 即 至 少 执行 两 次 ) 的 SQL 语句 保存 新 的 SQL 计划 
基线 。 为 此 ， 它 会 在 SQL 基础 管理 平台 中 管理 一 个 日 志 来 插入 每 条 它 处 理 的 SQL 语句 签名 。 这 代表 某 
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一 SQL 语句 第 一 次 执行 后 ， 它 的 签名 仅 会 插 和 日志。 然后 ， 当 同一 个 SQL 语句 第 二 次 执行 时 ， 会 创建 
仅 包 含 当 前 执行 计划 的 SQL 计划 基线 并 且 标 记 为 接受 。 从 第 三 次 执行 开始 ， 由 于 SQL 计划 基线 已 经 与 
SQL 语句 相关 联 ， 因 此 查询 优化 器 还 会 比较 当前 执行 计划 与 SQL 计划 基线 生成 的 执行 计划 。 如 果 它 们 
不 匹配 ， 这 代表 根据 当前 查询 优化 器 的 估算 ， 最 优 的 执行 计划 并 不 是 存储 在 SQL 计划 基线 中 的 那个 。 
为 了 保存 这 个 信息 ， 会 将 当前 执行 计划 添加 到 SQL 计划 基线 中 并 且 标 记 为 不 接受 。 然 而 ， 就 像 你 之 前 
看 到 的 那样 ， 当 前 执行 计划 无 法 使 用 。 会 强制 查询 优化 器 使 用 SQL 计划 基线 生成 的 执行 计划 。 图 11-9 
总 结 了 整个 处 理 过 程 。 


根据 SQL 语句 
签名 寻找 基线 


i CC 基线 是 否 可 用 ? 


对 比 使 用 与 未 使 用 
基线 的 执行 计划 


否 
保存 新 的 执行 计划 


图 11-9 自动 捕获 SQL 计划 基线 期 间 执行 的 主要 步骤 


将 某 个 新 的 执行 计划 存储 到 SQL 计划 基线 中 时 ， 重 点 需要 区 分 以 下 两 种 情况 。 

口 如 果 这 是 SQL 计划 基线 的 第 一 个 执行 计划 , 则 会 将 执行 计划 存储 为 接受 , 因此, 查询 优化 器 将 
能 够 使 用 它 。 

口 如 果 这 不 是 SQL 计划 基线 的 第 一 个 执行 计划 ,， 则 会 将 它 存储 为 不 接受 ， 因 此, 查询 优化 器 无 
法 使 用 它 。“ 进 化 SQL 计划 基线 ”部 分 将 介绍 如 何 使 SQL 计划 基线 生效 ， 以 使 其 对 查 优 化 咒 
可 用 。 


往日 志 中 插入 签名 
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@ 从 库 缓 存 中 加 载 

要 基于 存储 在 库 缓存 中 的 游标 手动 将 SQL 计划 基线 加 载 进 数据 字典 中 ， 可 以 使 用 dbms_spm 包 下 的 
load plans from cursor_ cache 辑 数 。 

实际 上 , 会 多 次 重 载 函数 来 支持 确定 必须 处 理 哪些 游标 的 不 同方 法 。 这 包含 两 种 主要 的 可 能 。 第 
一 ， 通 过 指定 以 下 属性 之 一 来 标识 多 个 SQL 语句 。 

口 sql_text: SQL 语句 的 文本 。 这 个 属性 支持 通配符 ( 例如 % )。 
口 parsing_schema_name: 用 来 解析 游标 的 模式 名 称 。 
口 module: 执行 SQL 语句 的 模块 名 称 ， 

口 action: 执行 SQL 语句 的 动作 名 称 。 

举例 说 明 ， 下 面 的 调用 引用 自 baseline from sqlareal1.sql 脚 本 ， 为 存储 在 库 缓存 中 包含 注释 
Mysqlstm 字 符 串 的 每 个 SQL 语句 创建 SQL 计划 基线 : 

ret := dbms spm.1load plans from cursor cache(attribute name => 'sql text', 

attribute value => '%/* MySqlStm */%'); 

第 二 ,通过 它 的 SQL ID 来 标识 SQL 语句 ， 以 及 可 选 执行 计划 的 散 列 值 。 如 果 散 列 值 没有 指定 或 设 
置 为 WILL， 所 有 对 指定 SQL 语句 可 用 的 执行 计划 都 会 被 加 载 。 下面 的 调用 ， 引 用 自 
baseline from sqlarea2.sql 脚 本 : 

ret := dbms_spm.load plans from cursor cache(sql id => '2y5r75r8y3sj0', 

plan_hash value => NULL); 

使 用 这 些 顶 数 加 载 的 执行 计划 会 被 存储 为 可 接受 ， 因 此 查询 优化 器 可 以 立即 利用 它们 

在 之 前 的 例子 中 ，SQL 计 划 基 线 基于 库 缓 存 中 找到 的 SQL 语句 的 文本 。 这 只 有 在 你 想 确 保 当 前 的 
执行 计划 未 来 也 会 被 用 到 时 才 有 关系 。 有 时 ， 使 用 SQL 计划 基线 的 目的 是 优化 SQL 语句 而 不 用 修改 应 
用 。 让 我 们 看 这 样 一 个 基于 baseline from sqlarea3.sql 脚 本 的 例子 。 

假设 应 用 执行 以 下 SQL 语句 。 查 询 优化 器 基于 全 表 扫 描 生 成 执行 计划 。 这 是 因为 在 SQL 语句 中 包 
含 一 个 hint， 该 hint 强 制 查询 优化 器 指向 此 操作 : 

SQL> SELECT /#+ full(t) */ count(pad) FROM t WHERE n = 42; 


SQL> SELECT * FROM table(dbms xplan.display cursor); 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
| 1| SORT AGGREGATE | | 
|* 2 | TABLE ACCESS FULL| T | 


2 - filter("N"=42) 
你 会 注意 到 限制 列 (wn) 上 有 索引 存在 。 接 着 你 或 许 想 知道 当 使 用 索引 时 性 能 会 怎样 。 因 此 ， 正 
如 下 面 的 例子 所 示 ， 使 用 某 个 hint 来 执行 SQL 语句 ， 以 确保 能 够 使 用 索引 : 
SQL> SELECT /*+ index(t) */ count(pad) FROM t WHERE n = 42; 
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SQL> SELECT * FROM table(dbms xplan.display cursor); 


SQL ID dat4n4845zdxc，child number 0 


| Id | Operation | Name | 


0 | SELECT STATEMENT | 
1 | SORT AGGREGATE | 
2 | TABLE ACCESS BY INDEX ROWID| 
:| INDEX RANGE SCAN | 


3 - access("N"=42) 

如 果 第 二 个 执行 计划 比 第 一 个 更 有 效率 ,你 的 目的 就 是 让 应 用 使 用 它 。 如 果 无 法 更 改 应 用 来 删除 
或 者 修改 hint, 可 以 利用 SQL 计划 基线 来 解决 这 个 问题 。 可 以 自动 或 者 手动 创建 SQL 计划 基线 来 达到 目 
的 。 在 这 种 情况 下 ， 你 决定 使 用 初始 化 参数 optimizer capture sql plan_baselines: 

SQL> ALTER SESSION SET optimizer capture Sqlzplan baselines = TRUE; 

SQL> SELECT /*+ full(t) */ count(pad) FROM 七 WHERE n = 42; 

SQL SELECT /*+ full(t) */ count(pad) FROM 七 WHERE n = 42; 


SQL> ALTER SESSION SET optimizer capture sql plan baselines = FALSE; 

一 旦 SQL 计 划 基 线 创建 好 ,就 要 检查 是 否 真 的 使 用 了 它 。 通 过 dbms_xplan 包 可 以 看 到 SQL 计 划 名 ， 
用 来 标识 生成 执行 计划 的 SQL 计划 基线 : 

SQL> SELECT /*+ full(t) */ count(pad) FROM t WHERE n = 42; 


SOL> SELECT * FROM table(dbms xplan.display cursor); 


| Id | Operation | Name | 


0 | SELECT STATEMENT | | 
| 1| SORT AGOREGATE | 
2 | TABLE ACCESS FULL|T | 


- SQL plan baseline SQL PLAN 3u6sbgq7v4u8z3fdbb376 used for this statement 
接着 , 基于 之 前 的 输出 提供 的 SQL 计 划 名 , 通过 dba_sql_plan baselines 视 图 ,可 以 找到 SQL 计 划 
基线 的 标识 符 ， 即 SQL 句柄 ( SQL handle ): 


SQL> SELECT sql handle 
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2 FROM dba sql plan baselines 
3 WHERE plan name = 'SQL PLAN 3u6sbgq7v4u8z3fdbb376'; 


SOL HANDLE 


SQL 3d1bob7d8fb2691f 

最 后 ， 你 使 用 SQL 计划 基线 蔡 换 执行 计划 。 要 这 么 做 ， 需 要 加 载 执行 索引 扫描 的 执行 计划 ， 并 移 
除 执行 全 表 扫 描 的 执行 计划 。 前 者 被 SQL 标识 符 以 及 执行 计划 散 列 值 引 用 ， 后 者 被 SQL 句柄 和 SQL 计 
划 名 引用 : 

ret := dbms_spm.load plans from cursor cache(sql handle => 'SQL 3d1ibob7d8fb2691f"，, 


sql id => 'dat4n4845zdxc'， 
plan_hash_value => '3694077449'); 


ret := dbms_spm.drop_sql_plan baseline(sql handle => 'SQL 3d1ibob7d8fb2691f", 
plan name => 'SQL PLAN 3u6sbgq7v4u8z3fdbb376'); 
要 检查 替换 是 否 成 功 ， 可 以 测试 新 的 SQL 计划 基线 。 请 注意 即使 SQL 语句 包含 full hint， 执 行 计 
划 也 不 会 再 使 用 全 表 扫 描 。 


注意 ”在 实践 中 ， 不 恰当 的 hint 经 常 导 致 低 效 的 执行 计划 。 能 够 使 用 这 部 分 技术 来 覆盖 它们 是 非常 有 


SQL> SELECT /*+ full(t) */ count(pad) FROM t WHERE n = 42; 


SQL> SELECT * FROM table(dbms xplan.display cursor); 


| Id | Operation | Name | 


0 | SELECT STATEMENT | 
1 | SORT AGGREGATE | 
2 | TABLE ACCESS BY INDEX ROWID| 
3 | INDEX RANGE SCAN | 


- SQL plan baseline SQL_ PLAN 3u6sbgq7v4u8z59340d78 used for this statement 
要 想 知 道 SQL 计 划 基 线 是 否 被 用 于 某 条 SQL 语 句 ， 也 可 以 查询 v$sql 视 图 的 sql_plan_baseline 列 。 
请 注意 该 列 显示 的 是 SQL 计划 名 ， 不 是 dbms xplan 包 显示 的 SQL 句柄 。 


@ 从 SQL 调 优 集中 加 载 
dbms_spm 包 下 的 lo0ad_plans_from_sqlset 函 数 ， 可 以 以 SQL 调 优 集 中 加 载 SQL 计 划 基 线 。 加 载 仅 需 
要 指定 所 有 者 ( owner ) 和 SQL 调 优 集 名 称 。 下 面 的 调用 ， 节 选 自 baseline_from_sqlset.sql 脚 本 : 
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ret := dbms spm.1oad plans from sqlset(sqlset name => 'test sqlset 5 
sqlset owner => user); 


使 用 该 函数 加 载 的 执行 计划 会 被 存储 为 可 接受 。 因 此 ， 查 询 优 化 器 可 以 立即 利用 它们 。 
升级 到 新 版 本 可 以 用 到 该 函数 。 实 际 上 ，10.2 版 本 的 数据 库 创建 的 SQL 调 优 集 也 可 以 加 载 到 11.2 
版 本 的 数据 库 中 。Baseline upgrade 10g.sql 和 baseline upgrade 11g.sql 脚 本 列举 了 这 样 的 应 用 。 


3. 显示 SQL 计 划 基 线 
通过 dba_sql_plan_baseline 视 图 ( 从 12.1 版 本 之 后 ， 也 可 以 查询 cdb_sql_plan_baselines 视 图 ) 可 
以 显示 可 用 SQL 计划 基线 的 基本 信息 。 要 显示 详细 信息 , 可 以 使 用 dbms_xplan 包 下 的 display_sql_plan_ 
baseline 陨 数 。 请 注意 它 与 第 10 章 讨论 的 dbms_xplan 包 下 的 男 一 个 函数 相似 。 下 面 的 例子 展示 了 它 可 
以 显示 的 信息 : 
SOLy SELECT: * 
2 FROM table(dbms xplan.display sql plan baseline(sql handle => 'SQL 971650b23f790eb7')); 


SQL handle: SOL 971650b23f790eb7 
SQL text: SELECT /* MySqlStm */ count(pad) FROM t WHERE n = 28 


Plan name: SQL PLAN 9f5khq8zrk3pr3fdbb376 Plan id: 1071362934 
Enabled: YES Fixed: NO Accepted: YES Origin : MANUAL-LOAD 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time 

| 0 | SELECT STATEMENT | | 1| 505 | 20 (0)| 00:00:01 | 
| 1| SORT AGGREGATE | | 1| 505| | | 
|* 2 | TABLE ACCESS FULL| T | 1| 505 | 20 (0)| 00:00:01 | 


2 - filter("N"=28) 


警告 要 想 在 11.1 版 本 和 11.2 版 本 中 正确 显示 SQL 计 划 基 线 的 信息 ，display_sql _plan_baseline 函 数 
必须 能 够 重 现 与 其 关联 的 执行 计划 。 如 果 函 数 无 法 实现 ， 它 会 返回 错误 的 结果 甚至 报错 信息 。 
为 了 避免 这 样 的 问题 ， 从 12.1 版 本 开始 ， 执 行 计 划 为 了 报告 而 存储 在 SQL 基础 管理 平台 中 。 可 
以 执行 baseline_unreproducible.sql 脚 本 来 观察 输出 结果 以 免 存 在 不 可 重 现 的 执行 计划 。 


不 幸 的 是 ,必须 在 11.1 版 本 中 查询 数据 字典 来 显示 与 SQL 计划 基线 关联 的 hint 列 表 。 下 面 的 SQL 语 
句 显示 了 一 个 示例 。 请 注意 ， 由 于 hint 被 存储 成 XML 格式 ， 因 此 需要 转换 成 可 读 的 输出 : 
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SQL> SELECT extractValue(value(h),'.') AS hint 
2 FROM sys.sqlobj$data od, sys.sqlobj$ so, 
3 table(xmlsequence(extract(xmltype(od.comp data),'/outline data/hint'))) h 
4 WHERE so.name = 'SOL PLAN 9f5khq8zrk3pr3fdbb376" 
5 AND so.signature = od.signature 
6 AND so.category = od.category 
7 AND so.obj type = od.obj type 
8 AND so.plan id = od.plan id; 


TGNORE_ OPTIM EMBEDDED HINTS 
OPTIMIZER FEATURES ENABLE('11.2.0.3') 
DB VERSION('11.2.0.3') 
ALL_ROWS 
OUTLINE LEAF(@"SEL$1") 
FULL(@"SEL$1" "T"@"SEL$1") 
然而 , 从 11.2 版 本 之 后 , 也 同样 可 以 使 用 display sql _ plan_baseline 函 数 来 显示 hint 列 表 。 实际 上 ， 
对 于 dbms_xplan 包 下 的 其 他 函数 , format 参 数 都 可 以 用 来 影响 它们 的 输出 。 下 面 的 例子 引用 自 将 format 
参数 设置 为 outline 时 产生 的 输出 : 
SOLS SELEGT, # 
2 FROM table(dbms xplan.display sql plan baseline(sql handle => "SQL 971650b23f790eb7 ， 
3 format => "outline' )); 


Outline Data from SMB: 


/省 
BEGIN OUTLINE_DATA 
TGNORE OPTIM EMBEDDED HINTS 
OPTIMIZER FEATURES ENABLE('11.2.0.3') 
DB_VERSION('11.2.0.3') 
ALL_ROWS 
OUTLINE LEAF(@"SEL$1") 
FULL(@"SEL$1" "T"@"SEL$1") 
END OUTLINE DATA 
4. 进化 SQL 计 划 基 线 
如 果 查 询 优 化 器 生成 的 执行 计划 不 是 与 它 正在 优化 的 SQL 语 句 相 关联 的 SQL 计 划 基 线 中 的 现 有 执 
行 计划 ， 就 会 将 一 个 新 的 未 接受 的 执行 计划 自动 添加 到 SQL 计 划 基 线 中 。 即 使 查询 优化 器 无 法 立即 使 
用 未 接受 的 执行 计划 时 也 会 发 生 。 这样 做 的 目的 是 保留 存在 另 一 个 可 能 更 好 的 执行 计划 的 信息 。 要 验 
证 一 个 未 接受 的 执行 计划 是 否 要 比 SQL 计 划 基 线 生成 的 执行 计划 更 好 时 ,就 必须 党 试 进化 (evolution ) 
这 仅仅 是 要 求 SQL 引擎 用 不 同 的 执行 计划 执行 SQL 语句 ， 并 查 明 未 接受 的 SQL 计划 基线 的 性 能 是 否 比 
接受 的 SQL 计划 基线 的 性 能 更 好 。 如 果 答 案 是 肯定 的 ， 则 会 将 未 接受 的 SQL 计划 基线 设置 为 接受 。 


警告 ”在 进化 期 间 SQL 引 擎 使 用 特殊 的 方式 处 理 SQL 语 句 。 实 际 上 ， 对 于 INSERT/UPDATE/MERGE/DELETE 
语句 ， 只 是 访问 数据 而 不 会 修改 数据 ， 因 此 ，SQL 语 和 句 仅 是 部 分 执行 。 然 而 ,我 认为 这 没什么 
问题 。 实 际 上 ， 和 修改 数据 的 操作 总 是 会 执行 相同 的 工作 ,而 并 不 取决 于 如 何 访问 修改 的 数据 
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可 以 使 用 dboms_spm 包 下 的 evolve_sql_plan_baseline 孔 数 来 执行 进化 。 要 调用 这 个 函数 , 除了 使 用 
sql_handle 和 /或 plan_name 参 数 来 确定 SQL 计划 基线 外 ， 还 需要 以 下 参数 。 
口 time_ limit: 以 分 钟 为 单位 , 进化 可 持续 的 时 间 。 这 个 参数 接受 自然 数 或 dbms_spm.auto_limit 
和 dbms_spm.no_limit 常 量 。 
口 Verify: 如 果 设 置 为 yes ( 默认 )， 则 会 执行 SQL 语句 以 验证 性 能 。 如 果 设 置 为 no， 就 不 会 执行 
验证 ,并且 SQL 计划 基线 也 会 简单 地 变 为 接受 。 
口 Commit : 如 果 设置 为 yes( 默认 ), 数 据 字 典 会 根据 进化 的 结果 做 修改 .如 果 设 置 为 no, 并 且 verify 
参数 设置 为 yes， 则 会 执行 验证 ， 但 不 修改 数据 字典 。 
报告 是 函数 的 返回 值 ， 它 提供 了 进化 的 详细 信息 。 下 面 的 例子 ， 引 用 自 baseline_automatic.sql 
脚本 生成 的 输出 ， 显 示 SQL 语 句 用 来 启动 进化 ， 并 且 结 果 报 告 指 出 SQL 计划 基线 被 进化 了 (包括 导致 
这 个 决定 的 统计 信息 ): 
SQL> SELECT dbms_spm.evolve sql plan baseline(sql handle => “SO0L 492bdb47e8861a89 " ， 


2 plan name => ”， 


3 time limit => 10， 

4 verify => 'yes', 

5 commit => 'yes') 

6 FROM dual; 

Evolve SQL Plan Baseline Report 

Inputs 

SOL HANDLE = SOL 492bdb47e8861a89 

PLAN NAME = 

TIME LIMIT = 10 

VERIFY = yes 

COMMIT = yes 


Plan: SQL PLAN 4kayv8zn8c6n959340d78 
Plan was verified: Time used .05 seconds. 
Plan passed performance criterion: 24.59 times better than baseline plan. 
Plan was changed to an accepted plan. 


Baseline Plan Test Plan Stats Ratio 
Execution Status: COMPLETE COMPLETE 
Rows Processed: 1 1 
Elapsed Time(ms): 二 好 .054 9.76 
CPU Time(ms) : .333 .111 3 
Buffer Gets: 74 3 24.67 
Physical Read Requests: 0 0 
Physical Write Requests: 0 0 
Physical Read Bytes: 0 0 
Physical Write Bytes: 0 0 
Executions: 1 1 
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Number of plans verified: 1 
Number of plans accepted: 1 


除了 刚刚 介绍 的 手动 进化 外 ，SQL 计 划 基 线 的 自动 进化 需要 Tuning Pack 选 件 支 持 。 原 因 是 ， 在 维 
护 窗口 期 间 ，SQL 优 化 顾问 处 理 SQL 语 句 会 对 系统 造成 重大 影响 。 在 可 能 的 情况 下 ， 优 化 顾问 提供 建 
议 来 改进 它们 的 响应 时 间 。 如 果 优 化 顾问 注意 到 未 接受 的 SQL 计划 基线 比 接受 的 SQL 计划 基线 的 性 能 
更 好 ， 它 会 建议 SQL 配置 文件 使 用 接受 的 SQL 计划 基线 。 显 然 ， 如 果 接 受 SQL 配置 文件 ， 则 也 会 接受 
SQL 计划 基线 。 因 此 ， 只 要 SQL 计划 基线 自动 接受 ,那么 SQL 优化 顾问 生成 的 SQL 配置 文件 也 会 月 动 
接受 。 

必须 要 指出 的 是 SQL 配置 文件 只 有 在 针对 SQL 优化 顾问 的 accept_sql_profile 参 数 设置 为 TRUE 时 
才 会 自动 接受 。 默 认 情况 下 是 FALSE。 你 可 以 借助 类 似 以 下 查询 通过 dba_advisor parameters 视 图 检查 
它 的 值 (请 注意 ， 同样 user 和 12.1 及 之 后 版 本 中 与 cdb 相 关 的 视图 也 存在 ): 


SQL> SELECT parameter value 
2 FROM dba advisor parameters 


3 WHERE task name = “SYS AUTO SQL TUNING TASK' 
4 AND parameter name = 'ACCEPT SQL PROFILES'; 


PARAMETER VALUE 


dbms_auto_sqltune 包 提供 了 set auto tuning task_parameter 过 程 用 来 更 改 accept _ sql _profiles 
参数 的 值 。 下 面 的 例子 展示 如 何 将 参数 设置 为 TRUE 来 激活 SQL 配 置 文件 的 自动 接受 : 
dbms_auto sqltune.set auto tuning task parameter(parameter => 'ACCEPT SQL PROFILES', 
value sx ‘TRUE ); 
从 12.1 版 本 开始 ， 又 有 了 一 个 新 的 顾问 叫 作 SPM 进 化 顾问 ( SPM Evolve Advisor )。 它 的 目的 是 为 
与 SQL 计划 基线 相关 联 的 未 接受 执行 计划 执行 进化 。 它 在 维护 窗口 期 间 执行 , 这 一 点 与 其 他 顾问 一 样 
可 以 使 用 dbms_spm 包 下 的 report_auto_evolve_ task 函数 来 显示 SPM 进 化 顾问 都 做 了 什么 。 如 果 只 调用 
这 个 函数 而 不 加 任何 参数 , 它 会 显示 最 后 一 次 执行 的 报告 。 下 面 的 例子 展示 了 当 最 后 三 次 执行 发 生 后 ， 
如 何 通过 dba advisor executions 视 图 找到 它 ( 请 注意 ， 同 样 user 和 12.1 及 之 后 版 本 中 与 cdb 相 关 的 视 
图 也 存在 )， 以 及 如 何 显 示 某 个 执行 的 报告 : 
SOL> SELECT * 
2 FROM ( 
SELECT execution name, execution start 
FROM dba advisor executions 
WHERE task name = 'SYS AUTO SPM EVOLVE TASK' 


3 
4 
2 本 
6 ORDER BY execution start DESC 
7 ) 

8 


WHERE rownum <= 3; 


EXECUTION NAME EXECUTION START 


EXEC 6294 23-APR-14 
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EXEC_6182 22-APR-14 
EXEC_6082 21-APR-14 


SQL> SELECT dbms spm.report auto evolve task(execution name => 'EXEC 6294') 
2 FROM dual; 


GENERAL INFORMATION SECTION 


Task Name : SYS AUTO SPM EVOLVE TASK 
Task Owner 5 SYS 

Description : Automatic SPM Evolve Task 
Execution Name : EXEC 6294 

Execution Type : SPM EVOLVE 

Scope : COMPREHENSIVE 

Status : COMPLETED 

Started : 04/23/2014 22:00:19 
Finished ; 04/23/2014 22:00:19 

Last Updated : 04/23/2014 22:00:19 
Global Time Limit  : 3600 

Per-Plan Time Limit : UNUSED 2 
Number of Errors :OO 


Number of plans processed : 0 
Number of findings 0 
Number of recommendations : 0 
Number of errors 2 站 


5. 修改 SQL 计划 基线 
创建 SQL 计划 基线 时 ， 可 以 使 用 Jbms_spm 包 下 的 alter sql_plan_baseline 过 程 来 修改 某 些 指定 的 
参数 。5ql_handle 和 plan_name 人 参数 确定 被 修改 的 SQL 计划 基线 。 必 须 指 定 这 两 个 参数 中 的 一 个 。 
Attribute _name 和 attribute_ value 参数 确定 被 修改 的 属性 以 及 它们 的 新 值 。Attribute_name 参 数 可 以 
接受 以 下 值 。 
口 enabled: 可 以 将 这 个 属性 设置 为 yes 或 no, 但 只 有 在 设置 为 yes 时 , 查询 优化 器 才 可 以 使 用 SQL 
计划 基线 。 
口 fixed: 将 这 个 属性 设置 为 yes 时 ， 不 会 将 新 的 执行 计划 添加 到 SQL 计划 基线 中 ,结果 就 是 之 后 
它 都 不 能 进化 。 此 外 , 如 果 SQL 计 划 基 线 包 含 多 个 可 接受 的 执行 计划 , 固定 的 执行 计划 要 比 未 
固定 的 好 。 可 以 将 这 个 值 设 置 为 yes 或 no。 
口 autopurge: 这 个 属性 设置 为 yes 的 SQL 计划 基线 会 在 一 段 时 间 不 使 用 后 自动 删除 ( 保留 时 间 的 
配置 会 在 稍 后 的 “删除 SQL 计划 基线 “部 分 介绍 )。 可 以 将 这 个 值 设置 为 yes 或 no。 
口 plan_name: 这 个 属性 用 来 更 改 SQL 计 划 名 。 它 可 以 是 不 超过 30 个 字符 的 任意 字符 串 。 
口 description: 这 个 属性 用 来 为 SQL 计 划 基 线 附加 描述 , 它 可 以 是 不 超过 500 个 字符 的 任意 字符 串 。 
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下 面 的 调用 中 禁用 与 执行 计划 关联 的 SQL 计划 基线 : 


ret := dbms_spm.alter sql plan_baseline(sql_handle => “SQL 492bdb47e88613a89 ， 
plan_name => 'SQL PLAN 4kayv8zn8c6n93fdbb376', 
attribute name => "enabled ， 
attribute value => 'no'); 


6. 激活 SQL 计划 基线 
查询 优化 器 只 有 在 初始 化 参数 optimizer use _ sql _ plan _baselines 设 置 为 TRUE ( 这 是 默认 值 ) 时 才 
会 使 用 SQL 计划 基线 。 可 以 在 会 话 或 系统 级 别 更 改 它 。 


7. 移动 SQL 计划 基线 

dbms_spm 包 提供 了 多 个 过 程 用 来 在 数据 库 之 间 移 动 SQL 计 划 基 线 。 比 如 ， 当 SQL 计划 基线 需要 在 
开发 环境 或 测试 数据 库 中 生成 然后 移动 到 生产 环境 中 时 。 正 如 图 11-10 所 示 ， 会 提供 以 下 特性 。 

口 可 以 使 用 create_stgtab_baseline 过 程 来 创建 临时 表 。 

口 可 以 使 用 pack_stgtab_baseline 函 数 将 SQL 计 划 基 线 从 数据 字典 复制 到 临时 表 中 。 

口 可 以 使 用 unpack_stgtab_baseline 函 数 将 SQL 计 划 基 线 从 临时 表 复 制 到 数据 字典 中 。 


通过 数据 迁移 
工具 复制 


图 11-10 使 用 dbms_spm 包 移动 SQL 计划 基线 


请 注意 ， 在 数据 库 之 间 移 动 临时 表 依靠 的 是 数据 移动 技术 ( 例如 ， 数 据 泵 ( Data Pump 或 旧 有 的 
导出 ( export ) 和 导 和 人 (import ) 程序 )， 而 不 是 依靠 dbms_spm 包 本 身 (参见 图 11-10 )。 

下 面 的 例子 引用 自 baseline_clone.sql 肢 本， 展示 了 如 何 将 SQL 计 划 基 线 从 一 个 数据 库 复制 到 另 
一 个 。 首 先 ， 在 当前 模式 下 创建 mystgtab 临 时 表 : 


dbms_spm.create stgtab baseline(table name => 'MYSTGTAB', 
table owner => User; 
tablespace name => 'USERS'); 


接着 将 SQL 计 划 基 线 从 数据 字典 复制 到 临时 表 中 。 可 以 通过 以 下 四 种 方法 识别 要 处 理 哪 些 SQL 计 
划 基 线 。 
口 通过 sql_handle 和 可 选 的 plan_name 参 数 来 准确 识别 SQL 计 划 基 线 。 
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口 选择 所 有 在 SQL 语句 文本 中 包含 特定 字符 串 的 SQL 计划 基线 。 为 此 ,可 以 使 用 支持 通配符 ( 例 
如 ，% ) 的 sql_text 参 数 。 请 注意 该 参数 区 分 大 小 写 。 

口 选择 所 有 符合 以 下 一 个 或 多 个 参数 的 SQL 计划 基线 : creator 、origin 、enabled 、accepted、 
fixed 、module 和 action。 如 果 指 定 了 多 个 参数 ， 那 么 就 需要 满足 它们 的 所 有 值 。 

口 处 理 所 有 SQL 计划 基线 。 这 种 方法 不 需要 指定 参数 。 

下 面 的 调用 展示 了 如 何 准确 识别 SQL 计划 基线 : 


ret := dbms spm.pack stgtab baseline(table name => 'MYSTGTAB', 
table owner => user, 
sql handle => 'SQL 492bdb47e8861a89 ， 
plan name => 'SQL PLAN 4kayv8zn8c6n93fdbb376'); 


此 时 ,依靠 数据 移动 程序 ， 将 mystgtab 临 时 表 从 一 个 数据 库 复 制 到 男 一 个 。 

最 后 ， 将 SQL 计划 基线 从 临时 表 复 制 到 目标 数据 库 的 数据 字典 中 。 要 识别 处 理 的 SQL 计划 基线 ， 
可 使 用 与 pack_stgtab baseline 孔 数 同样 的 方法 。 下 面 的 调用 展示 了 通过 SQL 语 句 的 文本 来 识别 SQL 
计划 基线 : 


ret := dbms_spm.unpack stgtab baseline(table name => “MYSTOTAB ， 
table owner => user, 
sql text => '%FROM t%'); 


8. 删除 SQL 计 划 基 线 

可 以 使 用 dbms spm 包 下 的 drop sql plan baseline 过 程 从 数据 字典 中 删除 SQL 计 划 基 线 。 
sql_handle 和 sql_name 参 数 指定 要 删除 的 执行 计划 和 /或 SQL 计划 基线 。 这 两 个 参数 至 少 需要 设置 一 个 。 
下 面 的 调用 说 明了 这 一 点 : 


ret := dbms spm.drop sql plan baseline(sql handle => "SQL_492bdb47e8861a89 ， 
plan name => 'SQL PLAN 4kayv8zn8c6n93fdbb376'); 


未 使 用 的 SQL 计划 基线 有 自动 删除 条 件 设 置 的 属性 设置 为 yes, 在 一 段 时 间 后 自动 删除 。 默认 的 周 
期 是 53 周 。 当 前 值 可 以 使 用 类 似 以 下 的 查询 通过 dba_ sql management_ config 视 图 查看 ( 在 12.1 及 之 后 
版 本 中 ， 也 存在 cdb 版 本 的 视图 ): 


SQL> SELECT parameter value 
2 FROM dba sql management config 
3 WHERE parameter name = 'PLAN RETENTION WEEKS'; 


PARAMETER VALUE 


可 以 调用 dbms_spm 包 下 的 configure 过 程 来 修改 保留 期 。 可 以 更 改 为 5 至 523 周 。 下 面 的 例子 展示 了 
如 何 更 改 为 12 周 。 如 果 将 parameter_value 参 数 设 置 为 NULL， 就 会 恢复 成 默认 值 : 


dbms_spm.configure(parameter name => 'plan retention weeks', 
parameter value => 12); 


9. 权限 
自动 捕获 SQL 计 划 基 线 时 ( 即 ， 通 过 将 初始 化 参数 optimizer_capture_sql plan_baselines 设 置 为 
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TRUE 来 实现 )， 并 不 需要 特别 的 权限 来 创建 它们 。 

dbms_spm 包 只 能 由 拥有 administer sql management object 系 统 权 限 的 用 户 执行 (默认 情况 下 ，dba 
角色 拥有 该 权限 )。SQL 计 划 基 线 并 不 存在 对 象 权限 。 

最 终 用 户 不 需要 特定 权限 也 可 以 使 用 SQL 计 划 基 线 。 


11.7.2” 何 时 使 用 


在 两 种 情况 下 ， 需 要 考虑 使 用 SQL 计划 基线 。 第 一 ， 需 要 优化 一 条 SQL 语句 而 不 能 在 应 用 中 修改 
它 时 ( 例如， 无 法 增加 hint )。 第 二 ， 遇 到 任何 原因 导致 的 执行 计划 不 稳定 时 。 由 于 SQL 计划 基线 的 目 
的 是 强制 查询 优化 器 为 给 定 SQL 语句 选择 指定 执行 计划 ， 因 此 仅 当 需要 明确 限制 查询 优化 需 选 择 单个 
执行 计划 时 才 会 使 用 该 技巧 。 

遗 城 的 是 ，SQL 计 划 基 线 仅 可 以 在 企业 版 中 使 用 。 标 准 版 请 使 用 存储 概要 替代 。 


11.7.3 ”陷阱 和 详 误 


SQL 计 划 基 线 最 重要 的 属性 之 一 是 它们 是 从 代码 中 分 离 的 。 然 而 这 也 会 带 来 问题 。 实 际 上 ， 由 于 
在 SQL 计划 基线 与 SQL 语句 之 间 并 没有 直接 的 关联 , 开发 人 员 很 可 能 会 彻底 忽略 SQL 计 划 基 线 的 存在 
结果 ， 如 果 开 发 人 员 修 改 SQL 语 句 将 会 导致 它 的 签名 发 生 改 变 ， 这 样 SQL 计 划 基 线 就 不 会 在 生效 了 。 
同样 ， 当 你 部 署 一 个 应 用 需要 依靠 SQL 计划 基线 来 保证 执行 正确 时 ， 必 须 记 得 在 数据 库 设置 期 间 安装 
它们 。 

需要 注意 的 是 ，SQL 计 划 基 线 依赖 的 对 象 删除 时 它 并 不 会 被 删除 。 但 这 并 不 是 问题 。 例 如 ， 如 果 
一 个 表 或 索引 因为 它 必 须 重 组 或 移动 而 需要 重建 ,* 那 么 SQL 计划 基线 没 被 删除 就 是 好 事 。 和 否则 ， 就 有 
必要 重建 它们 。 总 之 ,未 使 用 的 SQL 计划 基线 会 在 周期 过 后 被 删除 。 

两 个 有 相同 文本 的 SQL 语句 拥有 相同 的 签名 。 即 使 它们 引用 的 对 象 在 不 同 的 模式 下 。 这 代表 单个 
SQL 计划 基线 可 以 被 两 个 同名 但 是 不 同 模式 的 表 使 用 。 再 次 强调 ， 你 需要 小 心 ， 尤 其 是 数据 库 里 同样 
的 对 象 有 多 个 副本 时 。 

SQL 计划 基线 不 支持 引用 远程 数据 库 表 的 SQL 语句 。 

在 11.2.0.2 及 之 前 的 版 本 中 ,因为 Oracle Support 文 档 SOL profile notused in the Acive Physical Standby 
(10050057.8) 中 描述 的 bug， 导 致 SQL 计 划 基 线 在 Active Data Guard 环 境 下 受 限 。 可 以 在 主 实例 上 使 用 
SQL 计划 基线 ， 但 并 不 总 是 能 在 备用 实例 上 使 用 。 

SQL 计划 基线 存储 在 sysaux 表 空间 中 的 SQL 基础 管理 平台 上 。 默 认 情 况 下 ， 该 表 空 间 最 大 10% 的 
空间 会 留 给 它们 。 可 以 通过 dba_sql_management_config 视 图 显示 当前 值 : 

SQL> SELECT parameter value 


2 FROM dba sql management config 
3 WHERE parameter name = 'SPACE BUDGET PERCENT'; 


PARAMETER VALUE 


当 超 过 限制 的 时 候 ， 会 将 警告 信息 写 人 alert 日 志 中 。 要 改变 默认 的 限制 ， 可 以 使 用 dbms_spm 包 下 
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的 config 过 程 。 值 可 以 填写 1% ~ 50%。 下 面 的 例子 展示 了 如 何 将 它 的 值 更 改 为 5%。 如 果 将 
parameter value 参 数 设置 为 NULL， 参 数 就 会 恢复 默认 值 : 


dbms_spm.configure(parameter name => 'space budget percent', 
parameter Value => 5); 


当 SQL 语 句 有 SQL 配置 文件 和 存储 概要 时 ， 查 询 优 化 器 会 仅 使 用 存储 概要 。 当 然 ， 前 提 是 存储 概 
要 处 于 激活 状态 。 

当 SQL 语句 有 SQL 配置 文件 和 SQL 计划 基线 时 , 查询 优化 器 会 尝试 合并 与 SQL 配置 文件 关联 的 hint 
和 与 SQL 计划 基线 关联 的 hint。 然 而 ,合并 SQL 配置 文件 与 SQL 计划 基线 有 使 用 限制 。 实 际 上 ，SQL 计 
划 基 线 的 目的 是 强制 使 用 特定 的 执行 计划 。 结 果 ,， 在 考虑 使 用 SQL 计划 基线 之 前 ，SQL 配 置 文件 的 用 
处 或 许 只 是 生成 新 的 不 被 应 用 的 执行 计划 。 


11.8 “小结 


本 草 描 述 了 多 种 SQL 优 化 技巧 。 选 择 其 中 一 个 并 不 总 是 那么 简单 。 不 过 ， 如 果 你 理解 它们 的 工作 
原理 和 使 用 它们 的 利 浆 ,那么 选择 起 来 就 容易 多 了 。 即 便 如 此 ， 实 际 中 不 同 的 场景 也 会 限制 你 使 用 不 
同 的 技巧 。 这 或 许 是 因为 技巧 的 限制 或 授权 问题 。 

第 12 章 专门 介绍 解析 ， 这 是 执行 SQL 语句 的 核心 步 又 之 一 。 解 析 之 所 以 重要 是 因为 ， 当 查询 优化 
器 生成 执行 计划 时 , 为 了 总 是 能 有 高 效 地 执行 计划 , 你 会 希望 解析 每 条 由 数据 库 引擎 执行 的 SQL 语句 。 
但 是 相反 ,解析 也 是 一 个 昂贵 的 癌 作 。 结 果 就 是 必须 将 它 降 到 最 低 限 度 ， 并 且 执 行 计划 应 该 尽 可 能 地 
被 重用 ,但 不 是 重用 太 多 。 这 表示 执行 计划 并 不 总 是 高 效 的 。 为 了 最 大 可 能 地 利用 数据 库 引 擎 ， 必 须 
理解 工作 原理 和 不 同 特性 的 利弊 。 


解析 对 全 部 性 能 影响 的 可 变 因素 非常 多 。 在 某 些 情况 下 ， 可 以 简单 地 忽略 它 。 在 其 他 情况 下 ,， 它 
是 造成 性 能 问题 的 主要 原因 。 如 果 存 在 解析 问题 , 这 通常 代表 应 用 不 能 正确 处 理 它 。 这 是 个 主要 问题 ， 
因为 通常 要 改变 应 用 的 行为 ， 你 需要 修改 相应 的 代码 。 开 发 人 员 需 要 知道 解析 的 影响 以 及 如 何在 写 代 
码 时 尽 可 能 避免 相关 问题 。 

第 2 章 介绍 了 游标 的 生命 周期 和 解析 的 工作 原理 。 本 章 介 绍 如 何 识别 、 解 决 和 避 开 解析 问题 。 我 
也 会 介绍 与 解析 有 关 的 总 开销 。 最 后 ， 我 会 介绍 用 来 减少 解析 活动 的 通用 应 用 编程 接口 提供 的 特性 。 


12.1 识别 解析 问题 


当 寻 找 解 析 问 题 时 ， 很 容易 会 遇 到 强迫 性 的 混乱 优化 。 发 生 这 类 问题 的 原因 是 ， 多 个 动态 性 能 视 
图 包含 的 计数 器 详细 记录 了 软 解析 、 硬 解析 和 执行 的 次 数 。 这 些 计数 器 和 基于 它们 的 比率 一 样 ， 都 是 
没 用 的 ， 因 为 它们 没有 提供 关于 解析 花费 时 间 的 信息 。 请 注意 对 于 解析 ， 这 才 是 真正 的 问题 ， 因 为 它 
们 没有 标准 周期 。 实 际 上 ， 根 据 SQL 语 句 的 复杂 度 和 它 引用 的 对 象 ， 解 析 的 周期 通常 会 相差 几 个 数量 
级 。 简 单 地 说 ， 这 些 计数 器 只 能 告诉 你 数据 库 引擎 是 否 完成 少量 或 大 量 的 解析 ， 而 没有 关于 是 否 存在 
问题 的 信息 。 因 此 ， 实 际 中 它们 只 用 来 做 趋势 分 析 。 

如 果 你 遵循 第 一 部 分 和 第 二 部 分 提供 的 建议 , 那么 应 该 清晰 地 知道 ， 唯 一 有 效 识别 解析 问题 的 方 
法 ， 就 是 衡量 数据 库 引 擎 花费 了 多 少时 间 来 解析 SQL 语句 。 如 果 要 查找 单个 会 话 或 是 整个 系统 的 全 部 
时 间 信 息 ， 可 以 查询 提供 时 间 模 型 统计 信息 的 动态 性 能 视图 。 这 些 视图 包括 v$sess_time_model、 
v$sys_time_model 和 在 12.1 多 租户 环境 下 的 v$con_sys_time_model。 

例如 ， 下 面 查 询 的 输出 显示 了 一 个 会 话 花 费 了 大 量 时 间 (将 近 59% ) 来 解析 SQL 语 句 的 信息 : 

SOL> WITH 

2 db time AS (SELECT sid, value 

3 FROM v$sess time model 

4 WHERE sid = 137 

5 AND stat name = "DB time') 

6 SELECT ses.stat name AS statistic, 

7 round(ses.value / 1E6, 3) AS seconds, 

8 round(ses.value / nullif(tot.value, 0) * 1E2, 1) AS "%" 
9 FROM v$sess time model ses, db time tot 

10 WHERE ses.sid = tot.sid 


11 AND ses.stat name <> "DB time' 
12 AND ses.value > 0 
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13 ORDER BY ses.value DESC; 


STATISTIC SECONDS % 
DB CPU 18.204 99.3 
parse time elapsed 10.749 58.6 
hard parse elapsed time 8.048 43.9 
sql execute elapsed time 1.968 10.7 
connection management call elapsed time .021 
PL/SQL execution elapsed time .009 过 
Tepeated bind elapsed time 0 0 


类 似 于 这 个 查询 所 提供 的 信息 可 以 用 来 判断 解析 是 否 存 在 问题 。 不 幸 的 是 , 通过 动态 性 能 视图 提 
供 的 时 间 模 型 统计 信息 ， 并 不 能 帮助 找 出 是 哪个 SQL 语句 导致 的 问题 ! 

如 果 要 寻找 的 是 证 据 而 不 是 线索 , 那么 只 有 两 个 信息 来 源 可 以 使 用 : 由 SQL 跟踪 生成 的 输出 ， 和 
来 自 v$active_ session_history 或 dba_hist active sess_history 的 活动 会 话 历史 。 实 际 上 ， 在 SQL 语 
名 级 别 上 ， 这 些 是 仅 有 的 可 以 提供 关于 解析 定时 信息 的 来 源 。 这 就 是 为 什么 本 章 我 会 仅 基于 SQL 跟踪 
和 活动 会 话 历 史 来 讨论 解析 问题 的 识别 。 


注意 ”如果 想 使 用 活动 会 话 历 史 来 分 析 解 析 问 题 ， 需 要 知道 四 个 限制 。 第 一 ， 使 用 活动 会 话 历史 不 
仅 需 要 企业 版 ， 还 需要 Diagnostics Pack 选 件 。 第 二 ， 仅 在 11.1 及 之 后 版 本 中 ， 活 动 会 话 历史 才 
提供 用 于 分 析 解 析 问题 ( in_parse 和 in hard parse 标 识 ) 的 必要 信息 。 第 三 ,不 能 使 用 企业 管 
理 器 来 做 分 析 。 第 四 ， 了 既然 SQL 语 句 的 文本 无 法 直接 通过 活动 会 话 历史 获得 ( 只 能 得 到 SQL 
ID )， 那 么 获得 的 信息 并 不 一 定 足 够 用 来 识别 导致 解析 问题 的 SQL 语 和 句 ， 


解析 问题 主要 有 两 种 。 第 一 种 与 持续 时 间 非 常 短 的 解析 有 关 ， 称 为 快速 解析 (quick parse )。 当 然 
需要 大 量 执行 才 会 引起 注意 。 第 二 种 解析 问题 与 持续 时 间 很 长 的 解析 有 关 , 称 为 长 解析 ( long parses )。 
通常 是 在 SQL 语句 相当 复杂 或 查询 优化 器 需要 很 长 时 间 才 能 生成 高 效 执行 计划 时 才 会 出 现 。 这 种 情况 
下 与 执行 次 数 无 关 。 

在 接 下 来 的 两 节 里 ,我 会 介绍 用 来 识别 这 两 类 解析 问题 的 方法 。 既 然 对 于 这 两 种 问题 的 识别 没有 
本 质 的 区 别 ， 我 仅 会 全 面 介绍 第 一 种 。 


12.1.1 快速 解析 


接 下 来 介绍 如 何 定 位 快速 解析 导致 的 性 能 问题 。 针 对 11.2.0.3 版 本 的 数据 库 ， 执 行 ParsingTest1. 
java 文 件 中 的 类 来 生成 负载 样 例 。 同样 在 PL/SQL、C(OCI)、C# ( ODPNET ) 和 PHP ( PECL OCI8 扩 展 ) 
中 也 实现 了 同样 的 处 理 过程 。 鉴 于 在 第 3 章 中 介绍 过 两 个 探查 器 ，TKPROF 和 TVDS$XTAT ， 我 会 针 
对 这 两 个 探查 器 的 输出 文件 来 讨论 相同 的 例子 。 可 以 在 ParsingTest1.zip 文 件 中 找到 跟踪 文件 和 输 
出 文件 。 


1. 使 用 TKPROF 
正如 第 3 章 中 建议 的 那样 ，TKPROF 使 用 以 下 选项 执行 : 
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tkprof <trace file> 《Output file> sys=no sort=prsela,exeela,fchela 

要 开始 分 析 输 出 文件 ， 最 好 先 看 一 下 最 后 几 行 。 在 本 例 里 , 需要 重点 注意 的 是 处 理 持续 了 大 约 14 
秒 , 应 用 程序 执行 了 10 000 个 SQL 语 句 , 并 且 所 有 SQL 语句 都 不 相同 ( user SQL statements 与 unique SQL 
statements 相 等 )。 


1 session in tracefile. 
10000 user SQL statements in trace file. 

0 internal SQL statements in trace file. 
10000 SQL statements in trace file. 
10000 unique SQL statements in trace file. 
120060 lines in trace file. 

14 elapsed seconds in trace file. 


接着 ,需要 检查 输出 中 的 第 一 个 SQL 语 句 执行 了 多 长 时 间 。 由 于 指定 了 sort 选 项 ，SQL 语 句 可 
以 根据 其 响应 时 间 进 行 排 序 。 有 趣 的 是 ,第 一 个 游标 的 响应 时 间 要 小 于 百 分 之 一 秒 ( 0.00 )。 换 句 话 
说 ， 所 有 SQL 语句 的 执行 都 低 于 百 分 之 一 秒 。 实 际 上 ， 平 均一 个 执行 持续 了 1.4 毫 秒 ( 14/10 000 )。 
这 很 明显 意味 着 是 短 时 间 内 处 理 的 大 量 SQL 语 句 占用 了 大 量 的 响应 时 间 ， 而 不 是 少量 长 时 间 运 行 的 
SQL 语句 。 


call count cpu elapsed disk query current IOWS 
Parse 于 0.00 0.00 0 0 0 0 
Execute 1 0.00 0.00 0 0 0 0 
Fetch 0.00 0.00 0 2 0 0 
total 3 0.00 0.00 0 迷 0 0 


这 种 情况 下 ， 要 想 判 断 是 不 是 解析 的 问题 ， 就 必须 检查 总 计 的 部 分 。 根 据 执行 统计 信息 ， 解 析 时 
间 大 约 占 用 整个 执行 时 间 的 95% (5.7/6 )。 这 明显 证 明了 数据 库 引擎 除了 解析 什么 都 没 做 。 


call count cpu elapsed disk query current ITOWS 
Parse 10000 5.54 5.70 0 0 0 0 
Execute 10000 Qs17 QaTs 0 0 0 0 
Fetch 10000 0.13 0.14 0 23051 0 3048 
total 30000 5.86 6.00 0 23051 0 3048 


下 面 这 行 也 显示 这 10 000 个 解析 都 是 硬 解 析 。 注意, 即使 高 比例 的 硬 解 析 通 常 并 不 是 我 们 想 要 的 ， 
但 这 未 必 就 有 问题 。 但 这 证 明了 存在 次 优 的 部 分 。 

Misses in library cache during parse: 10000 

执行 统计 信息 的 问题 是 缺少 大 约 $7% ( 1-6.00 / 14 ) 的 响应 时 间 。 实 际 上 ， 通 过 查看 汇总 等 待 事 
件 的 表 ， 可 以 看 到 等 待 客户 端 用 去 了 6.24 秒 。 然 而 ， 仍 然 有 大 约 2 秒 ( 14 -6.00-6.24 ) 下 沙 不 明 。 


Event waited on Times Max. Wait Total Waited 
-=--------------------------------------- Waited ---------- ------------ 
SQL*Net message to client 10000 0.00 0.02 
SQL*Net message from client 10000 0.02 6.24 
latch: shared pool 5 0.00 0.00 


log file sync 1 0.00 0.00 
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当 你 知道 解析 出 了 间 题 时 ， 明 智 的 做 法 是 查看 一 下 SQL 语 句 。 本 例 中 ， 查 看 它们 其 中 的 一 些 即 可 
(下 面 是 排名 前 五 位 的 SQL 语句 ), 很 明显 它们 都 非常 类 似 。 只 有 在 WHERE 子 句 中 用 到 的 文字 不 同 。 这 是 
不 用 绑 定 变量 的 典型 案例 。 


SELECT pad FROM t WHERE val = 0 

SELECT pad FROM 七 WHERE val = 2139 
SELECT pad FROM t WHERE val = 9035 
SELECT pad FROM t WHERE val = 8488 


SELECT pad FROM 七 WHERE val = 1 


这 种 情况 的 问题 是 ，TKPROF 无 法 识别 只 有 文字 不 同 的 SQL 语句 。 实 际 上 ， 即 使 当 aggregate 选 项 
设置 为 yes ( 默认 就 是 )， 也 只 有 同样 文本 的 SQL 语句 会 集合 在 一 起 。 实 际 中 这 会 造成 TKPROF 很 难 对 
快速 解析 问题 进行 分 析 。 但 指定 record 选 项 可 以 使 这 个 过 程 简单 一 些 。 这 样 的 话 ， 文 件 仅 会 包含 生成 
的 SQL 语句 。 

tkprof <trace file> 《output file> sys=no sort=prsela,exeela,fchela record=<sql file> 

接着 可 以 使 用 命令 行 工 具 如 grep 和 wc 来 找 出 相似 的 SQL 语 句 有 多 少 条 。 例 如 ， 下 面 的 命令 返回 的 
值 是 10 000: 

grep “SELECT pad FROM t WHERE val =" <sql file> | wc -1 


2. 使 用 TVD$XTAT 

TVDSXTAT 不 需要 指定 特别 的 选项 : 

tvdxtat -i <trace file> -o <output file> 

俞 出 文件 的 分 析 从 查看 整体 资源 使 用 率 配置 文件 开始 。 人 处 理 持 续 了 14 秒 。 这 上段 时 间 中 ，43% 的 时 
间 花 在 了 等 待 客户 端 响应 上 ，40% 的 时 间 用 于 CPU 计算 。 这 里 的 指标 基本 与 上 一 部 分 介绍 的 一 致 。 只 
有 精度 不 同 。 在 第 一 部 分 唯一 附加 的 信息 是 准确 给 出 了 未 说 明 用 途 的 时 间 。 


Total Number of Duration per 
Component Duration % Events Event 
SOL*Net message from client 6.243 43.075 10,000 0.001 
CPU 5.862 40.444 n/a n/a 
unaccounted-for 2.364 16.309 n/a n/a 
SQL*Net message to Client 0.024 0.168 10,000 0.000 
latch: shared pool 0.000 0.002 5 0.000 
log file sync 0.000 0.002 1 0.000 
Total 14.494 100.000 


仅 观察 汇总 的 非 递 归 SQL 语 句 ， 可 以 看 到 全 部 的 处 理 操 作 只 有 单独 一 条 SQL 语 句 。 这 是 
TKPROF 和 TVD$XTAT 之 间 明 显 的 区 别 。 实 际 上 ，TVDS$SXTAT 识 别 类 似 的 SQL 语 句 ， 并 合 在 一 起 
记录 到 报告 里 。 


Statement Total Number of Duration per 
ID Type ”Duration % Executions Execution 
#1 SELECT 12.130 83.689 10,000 0.001 


#2 COMMIT 0.000 0.002 Ea 0.000 
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Total 12.130 83.691 

根据 没有 递归 语句 的 1 号 SQL 语 句 执 行 统 计 信息 ,解析 时 间 占 用 了 处 理 时 间 的 95% ( 5.705/6.009 ) 
这 清晰 地 表明 数据 库 引 擎 除了 解析 没有 做 其 他 事情 。TKPROF 和 TVD$XTAT 的 数据 文件 在 执行 统计 信 
息 上 略微 不 同 的 是 ，TVDSXTAT 在 解析 调用 数 旁 显示 未 命中 数 ( 换 句 话说 ， 硬 解析 )。 


Call Count Misses CPU Elapsed PIO LIO Consistent Current Rows 


Parse 10,000 10,000 5.548 5.705 0 0 0 0 0 
Execute 10,000 0 0.176 0.156 0 0 0 0 0 
Fetch 10,000 00.138 0.148 0 23,051 23,051 0 3,048 
Total 30,000 10,000 5.862 6.009 0 23,051 23;50Q54 0 3,048 


这 些 执行 统计 信息 的 问题 是 大 约 51% 的 响应 时 间 不 存在 。 不 管 怎样 ， 你 可 以 通过 查看 此 处 显示 的 
SQL 语 句 级 别 上 的 资源 使 用 率 配置 文件 ， 看 到 部 分 丢失 的 时 间 ; 特别 是 ， 等 待 客户 端 花 费 了 6.243 秒 ， 


Total Number of Duration per 
Component Duration % Events Event 
SQL#Net message from client 6.243 51.470 10,000 0.001 
CPU 5.862 48.327 n/a n/a 
SQL*Net message to client 0.024 0.201 10,000 0.000 
latch: shared pool 0.000 0.003 5 0.000 
Total 12.130 100.000 


3. 使 用 活动 会 话 历史 4 
活动 会 话 历 史 基 于 采样 。 因 此 要 执行 明智 的 分 析 ; 需要 大 量 的 采样 。 考 虑 到 测试 案例 1 只 执行 了 
十 几 秒 ,使 用 活动 会 话 历史 并 不 能 分 析出 准确 的 信息 。 本 节 的 目的 是 向 你 展示 查询 的 类 型 ， 你 或 许 想 
要 识别 哪个 SQL 语 句 被 解析 以 及 它 花 费 的 时 间 。 
在 活动 会 话 历 史 中 ，in_parse 和 in_hard_parse 标 志 告 诉 你 取样 时 会 话 是 否 在 解析 SQL 语句 。 基 于 
这 些 标志 ,可 以 针对 某 一 会 话 写 出 类 似 下 面 的 查询 , 来 评估 DB time 和 解析 SQL 语句 花费 的 时 间 ( 请 注 
意 ， 这 两 个 数字 的 单位 都 是 秒 ): 
SQL> SELECT count(*) AS db time, 
2 count (nullif(in parse, 'N')) AS parse time, 
FE: count(nullif(in hard parse, 'N')) AS hard parse time 
4 FROM v$active session history 


5 WHERE session id = 68 
6 AND session serial# = 23; 


DB_TIME PARSE TIME HARD PARSE TIME 


如 果 发 现 解析 有 问题 ( 比如 , 根据 上 一 个 数据 ，80% 的 时 间 用 于 解析 ), 你 不 仅 需要 知道 具体 解析 


的 SQL 语 句 ， 还 要 知道 每 条 语句 花费 的 时 间 。 不幸 的 是 ,活动 会 话 历史 其 中 一 个 局 限 性 就 是 并 不 能 直 
接 看 到 SQL 文本 。 要 获取 语句 文本 ， 需 要 基于 SQL ID 来 去 查询 男 一 个 视图 。 例 如 ， 可 以 将 v$active_ 
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session_history 联 接 到 v$sqlarea。 

不 幸 的 是 ,游标 保存 在 库 缓 存 中 的 时 间 很 短 ， 尤 其 是 因为 快速 解析 而 导致 繁忙 的 数据 库 实例 经 历 
性 能 问题 时 。 结 果 ， 你 或 许 无 法 获取 足够 的 信息 。 要 想 略 微 提 高 获取 更 多 信息 的 可 能 性 ， 可 以 使 用 
v$sqlstats 来 代替 v$sqlarea。 实 际 上 ， 前 者 有 更 大 的 保留 期 。 例 如 ， 下 面 的 查询 能 够 取 回 与 解析 相关 
的 四 个 采样 中 仅 有 的 两 条 SQL 语 句 ( 请 记 住 ,测试 案例 1 执行 了 10 000 条 SQL 语句 ): 


SQL> SELECT a.sql id, s.sql text, count(*) AS parse time 
2 FROM v$active session history a, v$sqlstats s 
3 WHERE a.sql id = s.sql id(+) 
4 AND a.session id = 68 
5 AND a,session serial# = 23 
6 AND a.in parse = “Y' 
7 GROUP BY a.sql id, s.sql text 
8 ORDER BY count(*) DESC; 


SQL ID SQL TEXT PARSE TIME 

a6z6qamdcwqdv 

2hcrrthw3w4y8 1 

aydfgrbd6mz1im SELECT pad FROM 七 WHERE val = 9580 

50m9q01tmghmw SELECT pad FROM 七 WHERE val = 7574 1 
A 


4. 总 结 问题 

通过 活动 会 话 历 史 执 行 的 分 析 对 本 例 来 说 并 不 是 
特别 有 帮助 。 这 是 因为 对 单个 会 话 在 十 几 秒 内 进行 采 
样 只 能 得 到 几 个 样本 。 然 而 ，TKPROF 和 TVDSXTAT 
执行 的 分 析 ， 清 晰 地 展示 了 数据 库 引 擎 单独 解析 的 处 
理 信 息 。 但 是 ， 在 数据 库 端 ， 解 析 只 占 了 全 部 响应 时 
间 的 39% ( 5.705/14.494 )。 

这 代表 排除 它 大 于 一 半 响 应 时 间 的 可 能 。 分 析 也 
显示 了 如 下 的 10 000 条 SQL 语句 只 解析 并 执行 一 次 : 

SELECT pad FROM t WHERE val = 0 

由 于 使 用 的 文字 不 断 变化 ， 在 库 缓存 中 的 共享 游 
标 无 法 重用 。, 换 句 话说 , 每 个 解析 都 是 硬 解 析 。 图 12-1 
图 示 了 这 个 处 理 。 


创建 语句 


关闭 语句 


图 12-1 测试 案例 1 执行 的 处 理 


注意 图 12-1 显 示 的 处 理 稍 后 会 被 当 作 测试 案例 1。 


毫 无 疑问 , 这 样 的 处 理 是 低 效 的 。 请 参考 12.2 他 ， 
找寻 对 应 的 解决 方案 。 
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12.1.2 长 解析 


接 下 来 的 部 分 将 介绍 如 何 识别 长 解析 造成 的 性 能 问题 。 但 是 , 不 包含 活动 会 话 历 史 , 原因 很 简单 ， 
解析 调用 很 难看 到 超过 几 秒 的 。 因 此 ， 大 多 数 时 候 通 过 活动 会 话 历 史 来 分 析 这 样 的 问题 是 不 明智 的 
总 之 ， 如 果 遇 到 解析 调用 花费 了 几 分 钟 的 情况 ， 那 么 使 用 活动 会 话 历史 进行 分 析 的 过 程 与 12.1.1 节 介 
绍 的 类 似 。 鉴 于 第 3 章 介 绍 了 两 个 探查 器 ，TKPROF 和 TVDSXTAT， 我 会 使 用 与 它们 的 输出 文件 相同 
的 例子 。 本 节 用 到 的 示例 跟踪 文件 是 通过 执行 1ong_parse.sql 脚 本 生成 的 。 跟 踪 文件 和 输出 文件 可 在 
long_parse.zip 文 件 中 找到 。 


1. 使 用 TKPROF 
与 快速 解析 一 样 ， 分 析 开 始 于 TKPROF 输 出 的 尾部 。 在 这 个 案例 中 ， 重 点 需要 注意 处 理 持续 了 大 
约 2 秒 而 应 用 仅 执行 了 3 条 SQL 语句 。 其 他 的 SQL 语句 都 是 有 数据 库 引 警 递 归 调 用 的 。 


1 session in tracefile. 

3 user SQL statements in trace file. 

13 internal SOL statements in trace file. 

16 SOL statements in trace file. 

16 unique SQL statements in trace file. 
9644 lines in trace file. 

2 elapsed seconds in trace file. 


通过 查看 输出 文件 中 第 一 个 SQL 语句 的 执行 统计 信息 ， 可 以 看 出 它 不 仅 占用 了 全 部 的 响应 时 间 
( 超过 2 秒 )， 而 且 所 有 的 时 间 都 用 在 单独 一 个 解析 上 : 


Call count cpu elapsed disk query current IOWS 
Parse 1 2.65 2.65 0 0 0 0 
Execute 1 0.00 0.00 0 0 0 0 
Fetch 2 0.00 0.00 10 10 0 1 
total 4 2.65 2.66 10 10 0 1 


2. 使 用 TVD$XTAT 
与 快速 解析 一 样 ，TVD$XTAT 输 出 分 析 始 于 查看 整体 资源 使 用 率 配置 文件 。 处 理 持续 了 2.8 秒 , 其 
中 98% 的 时 间 花 在 了 CPU 执行 上 。 还 要 注意 ， 在 本 例 里 ， 未 说 明 时 间 非 常 短 ， 因 此 完全 可 以 忽略 。 


Total Number of Duration per 
Component Duration % Events Event 
CPU 2.769 98.383 n/a n/a 
db file sequential read 0.027 0.943 314 0.000 
unaccounted-for 0.017 0.596 n/a n/a 
SQL*Net message from client 0.002 0.078 3 0.001 
SQL*Net message to client 0.000 0.000 3 0.000 
Total 2.814 100.000 


仅 通过 查看 非 递 归 SQL 语 句 汇 总 , 可 以 看 到 执行 了 3 条 SQL 语 句 。 其 中 一 条 SELECT 语 句 占用 了 几乎 
全 部 的 响应 时 间 。 
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Statement Total Number of Duration per 
ID Type Duration % Executions Execution 
#1 SELECT 2.791 99.167 1 2.791 
#9 PL/SOL 0.005 0.166 1 0.005 
#12 PL/SQL 0.002 0.071 1 0.002 
Total 2.797 99.404 


根据 导致 该 问题 SQL 语句 的 递归 执行 统计 信息 , 单独 一 个 解析 操作 占用 了 大 约 100%( 2.654/2.661 ) 
的 响应 时 间 。 这 清晰 地 显示 了 数据 库 引擎 除了 解析 没有 做 其 他 任何 事 。 


Call Count Misses CPU Elapsed PIO LIO Consistent Current Rows 
Parse 1 12.653 2.654 0 0 0 0 0 
Execute 1 00.002 0.002 0 0 0 0 0 
Fetch 2 0 0.004 0.006 10 10 10 0 1 
Total 4 1 2.659 2.661 10 10 10 0 1 


3. 总 结 问题 
分 析 显 示 单 个 SQL 语句 占用 了 几乎 全 部 的 响应 时 间 。 此 外 ， 整 个 响应 时 间 是 用 来 解析 这 个 SQL 语 
句 的 。 删 除 它 也 许 会 大 大 减少 响应 时 间 。 
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解决 解析 问题 很 明显 的 方式 是 避免 解析 。 但 这 并 不 总 是 可 行 。 实 际 上 ， 根据 解析 问题 是 与 快速 解 
析 有 关 还 是 与 长 解析 有 关 ， 你 需要 使 用 不 同 的 技巧 来 解决 问题 。 我 会 分 别 介绍 这 些 技巧 。12.1 市 中 使 
用 的 例子 将 用 作 解 释 解决 方案 的 基础 。 


注意 接 下 来 的 部 分 会 通过 性 能 测试 的 不 同 结果 ， 来 展示 解析 的 影响 。 性 能 指标 仅 用 来 辅助 对 比 不 
同 的 处 理 ， 使 你 更 好 地 理解 解析 的 影响 。 记 住 ， 每 个 系统 和 应 用 都 有 它们 各 自 的 特点 。 因 此 ， 
根据 环境 不 同 ， 使 用 的 技巧 也 会 不 同 。 


12.2.1 快速 解析 


本 节 介 绍 如 何 利 用 预 处 理 语句 来 避免 不 必要 的 解析 操作 。 鉴 于 执行 细节 跟 开发 环境 有 关 ， 这 里 无 
法 详细 介绍 。 在 本 章 稍 后 ,特别 是 12.4 节 ， 我 提供 了 关于 PL/SQL、OCI、JDBC、ODPNET 和 PHP 的 详 
细 信 息 。 


1. 使 用 预 处 理 语句 
当 一 个 SQL 语 句 使 用 不 断 变化 的 文字 导致 解析 问题 时 ， 首 先 要 做 的 是 使 用 绑 定 变 量 替换 文字 。 为 
此 , 你 需要 使 用 预 处 理 语句 ( prepared statement ), 使 用 预 处 理 语句 的 目的 是 让 所 有 相似 的 SQL 语 句 ( 这 
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些 语句 之 间 只 有 绑 定 变量 是 否 使 用 的 文本 差异 ) 共享 单个 游标 ,以 此 来 避免 不 必要 的 硬 解析 转换 成 软 
解析 。 图 12-2 图 示 了 案例 1 提升 测试 性 能 的 操作 。 


创建 预 处 理 语句 


设置 绑 定 变量 


关闭 语句 


图 12-2 ”测试 案例 2 执行 的 操作 


LA 一 


注意 ”图 12-2 显 示 的 操作 稍 后 将 作为 测试 案例 2 


正如 图 12-3 所 示 ， 随 着 性 能 的 提升 ， 与 测试 案例 1 相 比 ， 测 试 案例 2 的 响应 时 间 下 降 了 大 约 41% 
这 归功 于 预 处 理 语句 ， 因 为 新 的 代码 只 需要 执行 一 次 硬 解 析 。 因 此 ， 测试 案例 1 里 数据 库 引 和 擎 执行 的 
大 多 数 处 理 都 可 以 避免 。 但 是 ， 请 注意 仍 需 执行 10 000 个 软 解析 。 
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测试 案例 1 粳 SQL*Net message from client 
日 解析 
测试 案例 2 口 执行 & 获 取 


10 12 


秒 


图 12-3 ”对 比 测试 案例 1 和 测试 案例 2 的 数据 库 端 资源 使 用 率 配置 文件 ( 占用 少 于 1% 响 
应 时 间 的 组 件 不 会 显示 ， 因 为 它们 不 可 见 ) 


2. 重用 预 处 理 语句 

上 一 节 我 建议 使 用 预 处 理 语句 。 重 用 它们 可 以 更 好 地 清除 硬 解析 和 软 解 析 。 由 于 测试 案例 2 中 解 
析 的 运行 时 间 几 乎 可 以 忽略 ,你 应 该 考虑 一 下 原因 。 在 给 出 答案 之 前 ,请 查看 重用 单个 预 处 理 语 句 相 
天 处 理 的 性 能 指标 。 图 12-4 图 示 了 测试 案例 2 提升 性 能 的 操作 。 


关闭 语句 


图 12-4 测试 案例 3 执行 的 操作 
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注意 ”图 12-4 显 示 的 操作 稍 后 将 作为 测试 案例 3 


正如 图 12-5 所 示 , 随 着 性 能 的 提升 , 与 测试 案例 1 和 测试 案例 2 相 比 , 测试 案例 3 的 响应 时 间 分 别 下 
降 了 大 约 61% 和 33%。 这 归功 于 预 处 理 语句 ， 因 为 新 的 代码 只 需要 执行 一 次 硬 解析 。 因 此 ,测试 案例 1 
中 数据 库 引擎 执行 的 大 多 数 处 理 都 可 以 避免 。 但 请 注意 仍 需 执 行 10 000 个 软 解析 。 真 正 重 要 的 区 别 并 
不 在 解析 上 的 CPU time (在 测试 案例 2 中 已 经 非常 低 了 )， 而 是 对 SQLxNet message from client 等 待 的 
减少 造成 的 。 这 代表 你 在 网 络 或 客户 端 节省 了 资源 ， 也 可 能 这 两 方面 都 节省 了 资源 。 


测试 案例 1 

量 SQL"Net message from client 
测试 案例 2 日 CPU- 解析 

口 CPU - 执行 及 获取 
测试 案例 3 


图 12-5 ”对比 三 个 测试 案例 的 数据 库 端 资 源 使 用 率 配 置 文件 ( 占用 少 于 1% 响 应 时 间 的 
组 件 不 会 显示 ， 因 为 它们 不 可 见 ) 


在 测试 案例 2 中 ， 数 据 库 级 别 的 软 解析 执行 持续 了 大 约 十 分 之 一 秒 。 问 题 是， 提升 是 从 哪 来 的 ? 
肯定 不 是 来 自 数据 库 级 别 上 资源 使 用 率 的 降低 。 你 或 许 认 为 由 于 客户 端 与 服务 需 端 减少 了 通信 而 提高 
了 人 性能。 然而， 通过 查看 SOL*Net message from client 和 SQL*Net message to client 等 待 数 ， 可 以 发 
现在 这 三 个 测试 案例 中 并 没有 区 别 。 在 每 个 案例 中 ， 都 是 10 000 次 通信 。 显 然 这 是 因为 完成 了 一 万 次 
执行 ， 因此， 这 意味 着 在 这 个 案例 中 ， 所 有 必要 的 调用 ( 包括 解析 、 执 行 以 及 提取 的 调用 ) 都 被 客户 
端 驱动 程序 打包 到 单条 SQL#Net 消 息 中 了 。 然而 ， 在 网 络 层 客户 端 和 服务 需 端 传输 的 消息 大 小 不 同 
可 以 使 用 以 下 查询 来 获取 关于 它们 的 信息 : 

SELECT sn.name, ss.value 

FROM v$statname sn, v$sesstat SS 

WHERE sn.statistic# = ss.statistic# 


AND sn.name LIKE “bytes%client 
AND ss.sid = 42 


注意 在 SQL 语 句 级 别 , 无 法 检查 客户 端 与 服务 器 端 之 间 传 输 的 总 数据 量 ,。 因此， 上 一 个 查询 取 回 的 
统计 信息 是 会 话 级 别 上 的 。 在 这 个 案例 中 ， 这 么 做 没有 问题 ， 因 为 我 可 以 保证 这 个 会 话 仅 执 

行 我 的 测试 案例 的 SQL 语 句 ， 此 外 ， 我 通过 另 一 个 会 话 米 对 动态 性 能 视图 进行 查询 
图 12-6 显 示 了 三 个 测试 案例 的 网 络 流量 。 需要 重点 注意 的 是 , 在 测试 案例 2 中 , 切换 到 预 处 理 语句 
时 ， 由 数据 库 引 擎 接收 到 的 信息 大 小 略 有 增加 。 将 测试 案例 3 与 其 他 两 个 测试 案例 相 比 ， 最 重要 的 区 
别 是 大 量 减 少数 据 库 引擎 接收 和 发 送信 息 的 大 小 。 这 是 因 经 过 网 络 发 送 的 数据 为 了 打开 和 关闭 新 游标 
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( 在 测试 案例 3 中 ，SQL 语 句 的 文本 通过 网 络 发 送 ， 连 同 打开 游标 只 执行 一 次 ， 而 游标 也 在 最 后 仅 关 闭 
一 次 ) 而 引起 的 。 


1.5 
名 测试 案例 1 
各 1 日 测试 案例 2 
口 测试 案例 3 
0.5 六 
0.0 


通过 SQL*Net from 通过 SQL*Net to 
client 收 到 的 字 市 数 client 收 到 的 字 节 数 


图 12-6 三 个 测试 案例 中 单个 执行 的 网 络 流量 
由 于 通过 网 络 发 送 的 信息 大 小 不 同 ， 期望 的 响应 时 间 会 基于 网 络 速度 。 如 果 网 络 快 ， 客 户 端 与 服 
务 器 端 之 间 的 通信 影响 就 小 ， 或 者 甚至 可 以 忽略 。 如 果 网 络 慢 ， 影 响 会 很 大 。 图 12-7 显 示 了 两 种 网 络 
速度 的 啊 应 时 间 。 显 然 数 据 库 引擎 处 理 测试 案例 的 调用 时 间 并 不 依赖 网 络 速度 。 
测试 案例 1 测试 案例 2 测试 案例 3 


SQL’Net message 
from client 


各 DB 处 理 时 间 


1000 Mb/s 10 Mb/s 1000 Mb/s 10 Mb/s 1000 Mb/s 10 Mb/s 
图 12-7 ”三 个 测试 案例 在 两 种 网 速 下 的 响应 时 间 
即使 网 络 速度 对 整体 的 响应 时 间 影 响 非常 大 ,需要 重点 注意 的 还 是 三 个 测试 案例 对 客户 端 资源 的 
影响 ， 特 别 是 使 用 不 同 CPU 的 影响 。 图 12-8 显 示 了 三 个 测试 案例 中 客户 端的 CPU 使 用 率 。 测 试 案例 1 
和 测试 案例 2 的 指标 对 比 显 示 出 ， 使 用 绑 定 变量 会 对 客户 端 造成 开销 。 测 试 案例 2 和 测试 案例 3 的 指标 
对 比 显示 出 ， 创 建 和 关闭 SQL 语句 也 会 对 客户 端 造成 开销 。 


测试 案例 1 
测试 案例 2 日 CPU 时 间 


测试 案例 3 


0.0 0.5 1.0 1.5 2.0 
秒 
图 12-8 三 个 测试 案例 中 客户 端的 CPU 使 用 率 


3. 客户 端 语句 缓存 

如 果 应 用 打开 和 关闭 太 多 游标 而 导致 太 多 软 解析 ， 引 起 了 性 能 问题 ， 就 可 以 使 用 该 特性 来 解决 
测试 案例 2 就 是 这 个 问题 。 

客户 端 语句 缓存 的 概念 非常 简单 。 每 当 应 用 关闭 一 个 游标 , 代替 真实 的 关闭 , 客户 端 数据 库 层 ( 负 
责 与 数据 库 引擎 之 间 的 通信 ) 会 保持 它 打开 ， 并 将 其 添加 到 缓存 中 。 接 着 ， 稍 后 如 果 再 次 打开 和 解析 
基于 同样 SQL 语句 的 游标 , 代替 真正 的 打开 和 和 解析, 会 重用 客户 端 缓存 的 游标 。 因 而 不 会 发 生 软 解析 。 
基本 上 ,目标 是 使 应 用 的 行为 像 测试 案例 3 一 样 ， 即 使 它 的 写法 很 像 测试 案例 2。 

要 使 用 这 个 特性 ,通常 仅 需 要 应 用 它 并 定义 可 缓存 的 最 大 游标 数 。 请 注意 当 缓 存 满 了 时 ， 最 近 最 
少 使 用 的 游标 会 被 关闭 并 替换 成 新 游标 。 应 用 新 增 初始 化 代码 或 在 环境 中 设置 变量 时 会 触发 激活 。 它 
如 何 工 作 完 全 取决 于 开发 环境 ,本 章 稍 后 ,特别 是 在 12.4 节 ,会 提供 关于 PL/SQL .OCI、JDBC .ODPNET 
和 PHP 的 详细 信息 。 要 设置 最 大 缓存 游标 数 ， 需 要 了 和 解 使 用 的 应 用 。 如 果 不 知道 ， 应 该 分 析 它 并 找 出 
属于 高 软 解析 数 的 SQL 语句 数量 。 但 这 仅 是 首次 估算 。 之 后 > 仍 需要 执行 一 些 测试 来 确保 设置 了 正确 
的 值 。 总 之 ， 它 不 应 该 超过 初始 化 参数 open_cursors 的 值 。 

正如 图 12-9 所 示 ， 使 用 客户 端 语句 缓存 的 测试 案例 2 几乎 与 测试 案例 3 一 样 。 准确 地 说 ， 它 们 都 执 
行 了 一 个 硬 解 析 和 一 个 软 解析 。 因 此 ， 多 亏 了 语句 缓存 ,客户 端 处 理 大 幅度 下 降 . 


无 缓存 -测试 案例 1 


国 SQL*Net message from client 


缓存 -测试 案例 2 CPU 
无 缓存 -测试 案例 3 
秒 


图 12-9 对 比 使 用 和 不 使 用 客户 端 语句 缓存 的 数据 库 端 资源 使 用 率 配 置 文件 〈 占用 少 于 
1% 响 应 时 间 的 组 件 不 会 显示 ， 因 为 它们 不 可 见 ) 
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4. 总 结 

通过 利用 带 绑 定 变量 的 预 处 理 语句 来 避免 不 必要 的 硬 解析 有 时 很 重要 。 然 而 ， 当 使 用 它们 时 ， 你 
应 该 能 预料 到 会 在 客户 端的 CPU 使 用 率 和 网 络 流量 上 有 小 的 开销 。 你 可 以 证 明 这 个 开销 会 造成 性 能 问 
题 ， 因 此 预 处 理 语句 和 绑 定 变量 应 该 仅 在 必要 时 使 用 。 既 然 开 销 几 乎 可 以 忽略 不 计 ， 那么 最 佳 实践 就 
是 ， 只 要 它们 没有 导致 低 效 的 执行 计划 (更 多 详细 信息 ， 请 参考 第 2? 章 )， 就 应 该 尽 可 能 使 用 预 处 理 语 
句 和 绑 定 变量 。 每 当 预 处 理 语句 频繁 使 用 时 ， 就 应 该 重用 它 。 这 么 做 不 仅 可 以 避免 软 解析 ， 同 时 也 可 
以 降低 客户 端 CPU 使 用 率 和 减少 网 络 流量 。 唯 一 的 问题 是 ,一 个 预 处 理 语句 要 保持 打开 状态 就 会 使 用 
客户 端 和 服务 器 端 更 多 的 内 存 。 这 代表 当 每 个 会 话 保 持 上 千 个 游标 打开 时 需要 谨慎 处 理 ， 并且 只 有 在 
内 存 足 够 时 才 使 用 。 同 样 需要 注意 ， 初 始 化 参数 open_cursors 限 制 了 单个 会 话 同 时 打开 游标 的 数量 。 
万 一 缓存 了 许多 预 处 理 语句 ， 最 好 是 使 用 客户 端 语句 缓存 并 仔细 设置 缓存 大 小 ， 而 不 是 手动 保持 它们 
打开 。 这 样 的 话 ， 通 过 允许 有 限 的 预 处 理 语 名 缓存， 内 存 压 力 或 许 会 减轻 。 


12.2.2 ”长 解析 


如 果 长 解析 只 执行 了 几 次 (或 者 如 上 一 个 例子 ， 只 有 一 次 ), 通常 无 法 避免 长 解析 。 实 际 上 ，SQL 
语句 必须 至 少 解析 一 次 。 此 外 ， 如 果 SQL 语 句 很 少 执 行 ， 那 么 通常 必然 会 进行 硬 解 析 ， 因 为 在 各 次 执 
行 之 间 游 标 会 因 过 期 而 从 库 缓 存 中 交换 出 来 ， 龙 其 是 在 没有 使 用 绑 定 变量 的 时 候 。 因 此 ,唯一 可 能 的 
解决 方案 就 是 减少 它 自身 的 解析 时 间 。 

是 什么 导致 长 解析 时 间 ? 通常 ， 是 由 于 查询 优化 器 评估 了 太 多 不 同 的 执行 计划 。 此 外 ， 也 可 能 是 
由 于 执行 递归 调用 时 正在 进行 动态 采样 解决 后 者 的 方法 很 明显 : 要 么 降低 动态 采样 级 别 ， 要 么 彻底 
禁用 它 。 然 而 ,解决 前 者 会 有 些 麻烦 。 实 际 上 ， 要 缩短 解析 时 间 ， 必 须 减 小 评估 执行 计划 的 数量 。 这 
通常 可 以 通过 hint 或 存储 概要 来 强制 使 用 某 个 执行 计划 。 例如 , 在 12.1 节 的 例子 中 ，SQL 语 句 创建 存储 
概要 后 ， 解 析 时 间 缩 短 了 6 倍 ( 请 查看 图 12-10 )。 通 过 直接 指定 hint 在 SQL 语句 中 也 可 以 达到 同样 的 效 
果 ， 当 然 前 提 是 你 可 以 修改 代码 。 


不 使 用 存储 概要 
日 解析 时 间 
使 用 存储 概要 


0.0 0.5 1.0 1.5 2.0 2.5 3.0 


秒 
图 12-10 使 用 和 不 使 用 存储 概要 的 解析 时 间 对 比 


12.3” 避 开 解 析 问 题 


之 前 的 章节 描述 了 三 个 与 快速 解析 有 关 的 测试 案例 。 第 一 个 是 一 个 糟糕 代码 书写 的 例子 。 第 二 个 
比 第 一 个 要 好 得 多 。 第 三 个 在 大 多 数 情况 下 是 最 好 的 一 个 。 目 前 的 窘境 是 类 似 于 测试 案例 1 这 样 的 代码 
必须 修改 , 才 可 以 改善 性 能 ,但 遗憾 的 是 ， 这 并 非 总 是 可 行 的 。 这 是 因为 要 么 是 代码 不 可 用 ,技术 性 
壁垒 阻止 增强 代码 ( 例如 , 预 编译 语句 在 编程 环境 中 不 可 用 ), 要 么 是 实现 所 有 必要 的 修改 太 过 “昂贵 ”。 


388 第 12 章 解析 


接 下 来 的 部 分 会 介绍 如 何 处 理 这 样 的 问题 , 来 使 性 能 接近 不 存在 解析 问题 的 应 用 的 性 能 。 这 样 的 
方案 即使 性 能 不 能 与 正确 的 实现 一 样 好 ， 但 在 某 些 情况 下 也 比 什么 都 不 做 要 好 。 


注意 下 面 的 小 节 通 过 展示 不 同 的 性 能 测试 结果 来 描述 解析 的 影响 。 性 能 指标 只 用 来 辅助 对 比 不 同 
的 处 理 ， 使 你 更 好 地 理解 解析 的 影响 。 记 住 ， 每 个 系统 和 应 用 都 有 它们 各 自 的 特点 。 因 此 ， 
根据 环境 不 同 ， 使 用 的 技巧 也 会 不 同 。 


12.3.1 游标 共享 


这 项 功能 是 用 来 解决 由 应 用 程序 未 使 用 绑 定 变量 引起 的 性 能 问题 , 因为 这 样 做 会 导致 过 多 的 硬 解 
析 。 在 本 章 前 面 的 部 分 ， 我 在 测试 案例 1 中 指出 过 这 个 问题 。 

游标 共享 (cursor sharing ) 的 概念 很 简单 。 如 果 一 个 应 用 程序 执行 包含 文字 的 SQL 语句 ， 并 且 游 
标 共 享 处 于 启用 状态 , 那么 数据 库 引 警 会 自动 使 用 绑 定 变 量 替 换文 字 .。 这 样 , 对 于 只 有 文字 不 同 的 SQL 
语句 来 说 ， 硬 解析 可 能 会 转 为 软 解析 。 基 本 上 ， 有 目标 是 让 一 个 应 用 程序 表现 得 与 测试 案例 2 类 似 ， 即 
使 它 的 写法 与 测试 案例 1 类 似 。 


注意 ”游标 共享 不 会 蔡 换 通过 PL/SQL 执 行 的 静态 SQL 语 和 名 中 的 文字 。 对 于 动态 SQL 语 名 来 说 ， 只 有 
当 字 面值 不 会 与 绑 定 变量 混 消 的 时 候 才 会 发 生 替换 。 这 不 是 一 个 bug， 而 是 一 项 设计 决策 。 忆 
以 使 用 cursor _ sharing mix.sql 脚 本 来 重 现 这 种 行为 


游标 共享 是 通过 cursor_sharing 初 始 化 参数 控制 的 。 如 果 设 置 为 exact， 该 特性 会 被 禁用 。 换 句 话 
说 ， 只 有 当 SQL 语 句 的 文本 完全 相同 时 ， 它 们 才 会 其 享 父 游标 。 如 果 将 cursor_sharing 设 置 为 force 或 
similar， 则 会 启用 该 特性 。 默 认 值 是 exact。 可 以 在 系统 和 会 话 级 别 上 修改 它 。 也 可 以 在 SQL 语句 级 
别 上 通过 指定 cursor_sharing exact 提示 来 显 式 禁 用 游标 共享 。 

Oracle Support 文 档 1169017.1 ( Deprecating the cursor_sharing = “SIMILAR” setting ) 显示 ,从 11.1 
版 本 开始 , 将 废弃 cursor_sharing 初 始 化 参数 的 similar 值 。 此 外 ， 从 11.2.0.3 版 本 开始 , 将 这 个 参数 设 
置 为 similar 时 ， 数 据 库 引擎 会 将 其 作为 force 来 处 理 ! 废弃 值 similar 的 主要 原因 有 两 个 。 第 一 ， 你 很 
快 就 会 明白 ， 它 的 实现 存在 问题 。 第 二 ， 自 适应 游标 共享 ( 该 特性 的 相关 信息 请 参考 第 2 章 ) 的 引入 
使 得 没有 必要 再 使 用 similar。 事 实 上 ， 自 适应 游标 共享 可 以 在 游标 共享 设置 为 force 时 起 作用 。 


警告 游标 共享 以 不 稳定 而 闻名 。 这 是 因为 ， 经 过 这 些 年 , 找到 并 修复 了 与 之 相关 的 大 量 bug。 因 此 ， 
如 果 你 正在 考虑 使 用 它 ， 我 的 建议 是 仔细 查阅 Oracle Support 文 档 94036.1 ( Init.ora Parameter 
“CURSOR_SHARING” Reference Note )， 尤 其 是 已 知 bug 列 表 。 


鉴于 游标 共享 可 以 通过 两 个 值 来 启用 ，force 和 similar， 我 们 讨论 一 下 其 中 的 区 别 。 出 于 这 个 目 
的 ， 会 在 10.2.0.5 版 本 的 数据 库 上 分 别 使 用 不 同 的 cursor_ sharing 值 执行 测试 案例 1。 我 们 来 看 一 下 使 
用 值 force 时 的 结果 。 如 图 12-11 所 示 ， 测 试 案例 1 ( 使 用 值 force ) 中 的 数据 库 端 资源 使 用 率 配 置 文件 
与 测试 案例 2 中 的 类 似 。 实 际 上 ， 它 们 两 个 都 执行 了 一 次 单独 的 硬 解 析 和 9999 次 软 解析 。 结 果 ， 多 亏 
有 了 游标 共享 ,解析 时 间 大 幅 降 低 了 。 使 用 值 force， 只 是 在 CPU 使 用 率 上 有 轻微 的 改善 。 因 为 数据 库 
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引擎 为 了 使 用 绑 定 变 量 替 换 字 面值 而 必须 执行 更 多 的 工作 ， 但 这 是 在 预料 之 中 的 。 


EXACT- 测 试 案例 1 


国 SQL*Net message from client 
CPU 


FORCE- 测 试 案例 1 


EXACT- 测 试 案例 2 


图 12-11 将 游标 共享 设置 为 force 时 对 比 数据 库 端 资源 使 用 率 配置 文件 ( 这 里 不 会 显示 
响应 时 间 不 足 1% 的 那些 组 件 ) 


如 果 不 考 虑 自 适 应 游标 共享 , 值 force 相 关 的 问题 就 变 成 , 替换 文字 的 所 SQL 语句 会 共享 相同 的 文 
本 来 使 用 单个 子 游标 。 因 此 ,文字 ( 它 对 于 直方 图 来 说 很 关键 ) 只 有 在 与 第 一 条 提交 的 SQL 语句 关联 
的 执行 计划 生成 时 会 被 扫 视 到 。 当 后 续 的 执行 计划 中 使 用 的 文字 可 能 需要 不 同 的 执行 计划 时 ， 这 会 导 
致 性 能 问题 。 为 了 避免 这 种 情况 的 发 生 ， 可 以 使 用 值 similar。 事 实 上 ， 使 用 similar， 在 重用 一 个 已 
经 可 用 的 的 游标 之 前 , SQL 引 擎 会 检查 其 中 一 个 被 符 换 的 文字 是 否 有 对 应 的 直方 图 存在 。 如 果 不 存在 ， 
则 可 以 使 用 任何 有 兼容 执行 环境 的 子 游标 。 如 果 确 实 存在 ， 则 只 有 使 用 一 样 文字 创建 的 子 游标 才 可 以 
被 使 用 。 结 果 ， 使 用 similar 会 针对 每 一 个 文字 值 使 用 单独 的 游标 ( 使 用 更 少 的 内 存 )， 这 会 代替 针对 
每 个 文字 值 使 用 单独 的 父 游标 。 

如 图 12- a 在 测试 案例 1 中 , 使 用 值 similar 的 数据 库 端 资源 使 用 率 配 置 文件 要 表现 得 比 使 用 
值 exact 还 要 糟 。 问 题 不 仅 是 执行 了 10 000 次 便 解 析 ， 由 于 游标 共享 ， 这样 的 解析 操作 的 CPU 使 用 率 也 
会 更 高 。 事实 上 ， eee er tt 解析 时 间 直 线 上 升 ， 是 因为 在 
解析 期 间 ，SQL3| 擎 必须 检查 是 否 有 可 用 的 子 游标 可 以 重用 。 因 此 ， 必 须 扫 描 子 游标 的 列表 并 探测 每 
个 子 游标 的 兼容 性 。 简 单 来 说 ， 过 多 的 子 游标 抑制 了 良好 的 性 能 。 注 意 在 替换 完 文字 值 后 ， 所 有 SQL 
语句 拥有 相同 的 文本 。 因 此 ， 库 缓存 包含 着 单独 一 个 父 游标 ， 该 父 游标 拥有 成 千 的 子 游标 。 


EXACT- 测 试 案例 1 


四 SQL*Net message from client 
BCPU 


SIMILAR- 测 试 案例 1] 


EXACT- 测 试 案例 2 


图 12-12 ”将 游标 共享 设置 为 similar 时 比较 数据 库 端 资源 使 用 率 配置 文件 ( 这 里 不 会 显 
示 响 应 时 间 不 是 1% 的 那些 组 件 ) 


总 之 , 如 果 一 个 应 用 程序 使 用 文字 值 并 且 将 游标 共享 设置 为 similar, 其 性 能 取决 于 是 否 存在 相关 
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直方 图 。 如 果 它 们 存在 ，similar 的 表现 就 与 exact 类 似 。 如 果 它 们 不 存在 ，similar 表 现 就 与 force 类 
似 。 这 意味 着 如 果 面 临 解析 问题 ， 通 常 使 用 similar 是 没有 意义 的 。 


12.3.2 ”服务 器 端 语句 缓存 


这 个 功能 与 客户 端 语句 缓存 类 似 ， 它 是 用 来 在 发 生 过 多 的 软 解析 时 减少 负载 的 。 从 概念 上 来 看 ， 
这 两 种 类 型 的 语句 缓存 是 类 似 的 ， 除 了 一 个 在 服务 器 端 实现 ， 另 一 个 在 客户 端 实现 。 从 性 能 的 角度 来 
看 ,差别 还 是 很 大 的 。 事实 上 ， 服 务 器 端 实 现 远 不 及 客户 端 实现 强大 。 这 是 因为 服务 器 端 实现 仅 在 服 
务 右 端 减少 软 解析 的 负载 ， 而 多 数 情况 下 ， 客 户 端 软 解析 的 负载 远 比 服务 器 端 要 大 。 实 现 服务 器 端 语 
句 缓存 的 唯一 优势 ， 是 可 以 在 数据 库 引擎 中 缓存 部 署 的 PL/SQL 或 Java 代 码 执 行 的 SQL 语句 。 

如 果 一 个 应 用 程序 执行 大 量 的 软 解析 , 在 库 缓 存 的 站 和 互 斥 上 过 高 的 压力 也 会 导致 在 数据 库 引 警 
上 出 现 显著 的 争 用 。 下 面 的 数据 库 端 资源 使 用 率 配置 文件 展示 了 这 样 情况 。 当 数据 库 引擎 为 相同 的 
SQL 语句 每 秒 处 理 超过 30 000 次 解析 时 ,启动 了 测试 案例 2。 尽 管 这 肯定 不 是 一 个 正常 的 负载 ， 但 它 有 
助 于 证 实 服务 器 端 游 标 缓存 的 影响 。 


Total Number of Duration per 
Component Duration % Events Event 
SQL*Net message from client 4.166 54.569 10,000 0.000 
library cache: mutex X 2.622 34.339 158 0.017 
CPU 0.557 7.294 n/a n/a 
latch free 0.265 3.473 1 0.265 
SQL*Net message to client 0.014 0.177 10,000 0.000 
cursor: pin 5 0.011 0.148 1 0.011 
Total 7.635 100.000 


一 且 服 务 器 端 软 解析 的 负载 影响 性 能 而 又 无 法 修改 应 用 程序 时 ， 服 务 器 端 语 句 缓存 可 能 会 有 帮 
助 。 这 个 例子 中 ,在 启用 并 施加 相同 的 负载 后 ， 产 生 的 资源 使 用 率 配置 文件 如 下 所 示 。 注 意 关联 到 库 
缓存 的 门 锁 和 互 斥 上 的 大 部 分 等 待 已 消失 。 


Total Number of Duration per 
Component Duration % Events Event 
SQL*Net message from client 4.646 85.959 10000 0.000 
CPU 0.420 7.769 n/a n/a 
cursor: pin S 0.328 6.070 2 0.164 
SOL*Net message to client 0.011 0.202 10000 0.000 
Total 5.405 100.000 


服务 器 端 语 句 缓 存 是 通过 session_cached_cursors 初 始 化 参数 配置 的 。 它 的 值 指定 每 个 会 话 能 够 缓存 
的 最 大 游标 数量 。 所 以 如 果 将 它 设置 为 0, 就 会 禁用 该 特性 。 反 之 如 果 设 置 的 值 大 于 0, 则 会 启用 该 特性 。 
在 102 版 本 中 ， 上 默认 值 是 20， 从 11.1 版 本 开始 ， 默 认 值 是 50。 在 系统 级 别 上 ， 只 有 重启 实例 才能 改变 它 。 
在 会 话 级 别 上 ， 可 动态 修改 该 参数 。 与 客户 端 语句 缓存 一 样 ， 要 决定 缓存 游标 的 最 大 数量 ， 需 要 了 解 正 
在 使 用 的 应 用 程序 ， 或 分 析 以 找 出 有 多 少 SQL 语句 产生 了 大 量 软 解析 。 然 后 ， 根 据 这 个 初步 的 估算 ， 有 
必要 进行 一 些 测试 来 验证 这 个 值 是 否 合适 。 在 这 些 测 试 期 间 ， 要 验证 缓存 是 否 有 效 ， 可 以 通过 验证 对 响 
应 时 间 的 影响 , 也 可 以 通过 从 下 面 的 查询 中 查看 统计 结果 来 验证 。 注 意 ,， 在 系统 级 别 上 也 有 相同 的 统计 
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言 县 可 用 。 无 论 如 何 ， 应 该 关注 单独 一 个 存在 负债 问题 的 会 话 ， 以 便 找 出 可 用 的 线索 。 


SOL> SELECT sn.name, ss.value 
2 FROM v$statname sn, v$sesstat ss 
3 WHERE sn.statistic# = ss.statistic# 
4 AND sn.name IN ('session cursor cache hits', 
5 'session cursor cache count', 
6 ‘parse Count (total)') 
7 AND ss.sid = 42; 


NAME VALUE 
session cursor cache hits 9997 
session cursor cache count 9 
parse count (total) 10008 


第 一 ， 将 缓存 游标 的 数量 ( session cursor cache count ) 与 session_cached cursors 初 始 化 参数 
的 值 进行 对 ! 蕊 。 如 果 前 者 小 于 后 者 , 则 意味 着 增加 该 初始 化 参数 的 值 应 该 对 缓存 的 游标 数量 没有 影响 。 
否则 ， 如 果 两 个 值 相 等 ， 增 加 该 初始 化 参数 的 值 可 能 有 助 于 缓存 更 多 的 游标 。 无 论 如 何 ， 超 过 
open_cursors 初 始 化 参数 的 值 都 是 没 意 义 的 。 例 如 ， 根 据 上 面 的 统计 信息 ， 现 在 缓存 中 有 九 个 游标 。 
因为 测试 期 间 session_cached cursors 初 始 化 参数 被 设置 为 90， 增 加 它 的 值 就 没有 用 处 

， 使 用 这 些 附加 的 指标 ， 可 以 检查 相对 于 解析 调用 的 总 数 (parse count (total) )， 有 多 少 

解析 调用 是 通过 服务 器 端 语 句 缓存 优化 的 (session cursor cache hits )。 如 果 两 个 值 接 近 ， 可 能 并 不 
值得 花 时 间 增 加 缓存 的 大 小 。 在 上 面 这 些 统计 信息 中 ， 因 为 缓存 避免 了 超过 99% ( 9997/10 008 ) 的 解 
析 ， 所 以 增加 它 很 可 能 没什么 意义 


由 parse count (total) 和 session cursor cache hits 统 计 信 息 提供 的 值 经 常会 引起 几 个 bug。 
这 些 bug 中 你 最 可 能 碰 到 的 是 以 下 这 些 

口 从 11.1.0.6 版 本 开始 ，session cursor cache hits 统 计 信 息 会 为 利用 PL/SQL 客 户 端 语句 缓存 的 
游标 增加 数值 。 因 此 ，session cursor cache hits 统 计 信 息 可 能 会 比 parse count (total) 统 计 
信息 高 出 许多 。 默 认 情 况 下 会 将 客户 端 语句 缓存 在 PL/SQL 程 序 中 。 因 此 ,使 用 PL/SQL 时 ， 
session cursor cache hits 统 计 信 息 就 变 得 没 用 了 。 

口 从 11.2.0.1 版 本 开始 ， 会 话 级 别 上 的 session cursor cache hits 统 计 信 息 存 储 在 一 个 占用 16 位 
的 无 符号 整数 中 。 因 此 ， 命 中 超过 65 $35 次 的 会 话 会 洪 出 ， 并 且 值 会 从 0 重新 开始 。 而 且 ， 即 
使 这 个 统计 信息 在 系统 级 别 没 有 这 样 的 限制 ， 在 会 话 级 别 的 溢出 仍然 会 引起 系统 级 别 的 统计 信 
息 减 少 65 535。 结 果 ，session cursor cache hits 统 计 信 息 在 系统 和 会 话 级 别 上 几乎 没有 用 处 。 

口 在 11.2.0.3 版 本 中 ，parse count (total) 统 计 信 息 并 没有 为 使 用 服务 器 端 语 向 缓存 的 游标 增加 
数据 。 结果，session cursor cache hits 统 计 信 息 要 比 parse count (total) 统 计 信息 的 值 高 得 
多 。 由 于 默认 会 使 用 服务 器 端 语句 缓存 ， 实 际 上 parse count (total) 统 计 信 息 在 11.2.0.3 版 本 
中 没有 实际 用 处 。 该 bug 在 11.2.0.4 版 本 中 已 修复 

综 上 所 述 ， 当 依赖 并 解释 session cursor cache hits 统 计 信 息 时 ， 要 十 分 小 心 。 回 顾 已 知 bug 


来 确保 没有 适用 于 你 的 情况 ， 特 别 是 要 记 住 这 里 列 出 的 三 个 bug。 
I EPE 二 EECEEEeEEEEESES==5 
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在 之 前 的 统计 信息 中 还 有 一 件 重 点 需要 注意 的 事情 ,缓存 中 “只 有 ”9997 次 命中 。 既 然 测 试 案 例 
2 执行 了 相同 的 SQL 语 句 10 000 次 , 为 什么 不 是 9999? 答案 是 一 个 游标 只 有 在 它 已 经 被 执行 多 次 的 情况 
下 才 会 被 放 入 游标 缓存 中 。 这 么 做 的 原因 是 防止 缓存 那些 只 执行 一 次 的 游标 。 获 得 9999 这 个 数 ， 只 能 
是 在 第 一 次 解析 调用 之 前 就 已 经 有 一 个 可 共享 游标 存在 于 库 缓 存 中 。 

总 之 ， 服 务 器 端 语句 缓存 是 一 个 重要 的 功能 。 事 实 上 ， 如 果 正 确 设置 大 小 ， 它 可 能 会 节省 一 些 服 
务 器 端的 负载 。 然 而 , 不 能 因为 这 个 功能 , 应 用 就 找 借口 不 再 管理 游标 。 这 是 因为 正如 你 上 面 看 到 的 ， 
当 缓 存在 服务 需 端 执行 而 不 是 客户 端 执 行 时 ， 解 析 的 负载 会 更 高 。 


12.4 ”使 用 应 用 编程 接口 


本 节 的 目标 是 描述 与 为 不 同 的 应 用 编程 接口 解析 相关 的 功能 。 在 之 前 章节 的 描述 中 ,为 了 避免 不 
必要 的 硬 解析 和 软 解析 , 应 该 有 三 个 关键 的 功能 可 以 使 用 : 绑 定 变量 、 重 用 语句 以 及 客户 端 语 句 缓存 。 
表 12-1 总 结 了 在 不 同 的 应 用 编程 接口 中 这 些 特性 的 可 用 情况 。 接 下 来 的 小 节 会 为 PL/SQL .OCI、JDBC、 
ODP.NET 以 及 PHP 提 供 一 些 详细 的 信息 。 


表 12-1 ”由 不 同 的 应 用 编程 接口 提供 的 功能 概览 
应 用 编程 接口 绑 定 变量 语句 重用 客户 端 语句 缓存 

Java 数据 库 连 接 (JDBC) 
java.sql.Statement 
java.sql.PreparedStatement 
Oracle Call Interface (OCT) 
Oracle C++ Call Interface (OCCI) 
Oracle Data Provider for .NET (ODP.NET) 
Oracle Objects for OLE (O040) VvV 
Oracle Provider for OLE DB VvV Vv 
PHP (PECL OCI8 扩展 ) Vv Vv Vv 
PL/SQL 

静态 SQL 

本 地 动态 SQL(EXECUTE IMMEDIATE) 

本 地 动态 SQL(OPEN/FETCH/CLOSE) 

使 用 dbms_sql 包 的 动态 SQL 
预 编译 程序 
SQLJ 


必 站 ,二 攻 
< 
< 


有 
< 


12.4.1 PL/SQL 


PL/SQL 提 供 了 不 同 的 方法 来 执行 SQL 语 句 。 主 要 的 两 个 类 别 是 静态 SQL 和 动态 SQL。 动 态 SQL 能 
够 进一步 分 成 三 个 子 类 别 : EXECUTE IMMEDIATE 、OPEN/FETCH/CLOSE 以 及 dbms_sql 包 。 唯 一 与 解析 相关 的 
功能 是 它们 都 可 以 使 用 绑 定 变 量 。 而 实际 上 ， 只 有 重用 语句 和 缓存 客户 端 语句 的 部 分 可 以 使 用 。 它 们 
并 不 是 对 所 有 SQL 语句 类 别 都 有 效 。 接 下 来 的 小 节 将 会 描述 这 四 种 类 别 的 每 个 细节 。 
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注意 鉴于 PL/SQL 是 在 数据 库 引 擎 中 运行 的 ， 讨 论 客户 端 语句 缓存 好 像 有 点 奇怪 。 其 实 ， 从 SQL 引 
擎 的 视角 来 看 ，PL/SQL 引 擎 就 是 一 个 客户 端 。 在 这 个 客户 端 中 ， 客 户 端 语 自 缓存 的 概念 将 在 
这 里 实现 。 


在 本 节 例 子 中 提供 的 PL/SQL 代 码 块 来 自 ParsingTest1.sql、ParsingTest2.sql 以 及 ParsingTest3.sql 
脚本 ， 分 别 实现 测试 案例 1、2 和 3。 


1. 静态 SQL 

静态 SQL 被 集成 到 PL/SQL 语 言 中 。 就 像 它 的 名 称 一 样 它 是 静态 的 , 因此 , 在 PL/SQL 编 译 期 间 SQL 
语句 必须 是 完全 已 知 的 。 出 于 这 个 原因 ， 如 果 一 条 SQL 语 句 引 用 了 PL/SQL 变 量 , 则 不 可 避免 地 要 使 用 
绑 定 变量 。 例 如 ， 不 可 能 使 用 静态 SQL 写 出 一 段 代 码 来 重 现 测试 案例 1。 

编写 静态 SQL 有 两 种 方式 。 第 一 种 是 基于 隐 式 游标 ， 但 它 没有 控制 游标 生命 周期 的 能 力 。 下 面 的 
PL/SQL 代 码 块 实现 了 测试 案例 2 : 

DECLARE 


1 _ pad VARCHAR2(4000); 
BEGIN 
FOR i IN 1..10000 了 
LOOP 
SELECT pad INTO 1 pad 
FROM 七 
WHERE val = i; 
END LOOP; 
END; 


第 二 种 方式 是 基于 显 式 游 标 。 在 这 种 情况 下 ， 可 以 对 游标 进行 某 些 控制 。 不 管 怎样 ， 打 开 / 解 析 / 
执行 阶段 被 合并 成 一 个 单独 的 操作 ( OPEN )。 这 意味 着 仅 可 以 控制 提取 和 关闭 阶段 。 下 面 的 PL/SQL 代 
码 块 实现 了 测试 案例 2: 

DECLARE 

CURSOR c (p val NUMBER) IS SELECT pad FROM t WHERE val = p_val; 
1_ pad VARCHAR2(4000); 
BEGIN 
FOR i IN 1..10000 
LOOP 
OPEN c(i); 
FETCH c INTO 1 pad; 
CLOSE €; 
END LOOP; 
END; 


尽管 这 两 种 方式 都 防止 了 不 良 代码 ( 测试 案例 1 ), 但 它们 也 不 允许 写 出 特别 高 效 的 代码 ( 测试 案 
例 3 )。 这 是 因为 没有 完全 控制 游标 。 但 从 性 能 的 角度 看 ， 这 两 种 方法 是 类 似 的 。 

为 了 解决 这 个 问题 ， 可 以 使 用 客户 端 语句 缓存 。 缓 存 游 标的 最 大 数量 由 session_cached_cursors 
初始 化 参数 决定 。 在 10.2 版 本 中 ， 默 认 的 缓存 游标 数量 是 20， 而 从 11.1 版 本 开始 是 50。 这 个 初始 化 参 
数 ， 并 不 与 客户 端 语 句 缓存 直接 相关 ， 而 是 “错误 ”地 配置 了 它 ! 事实 上 ， 这 与 用 于 控制 服务 器 端 语 
句 缓存 的 初始 化 参数 是 同一 个 。 
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2. 本 地 动态 SQL: EXECUTE IMMEDIATE 
从 游标 管理 的 角度 来 看 , 基于 EXECUTE IMMEDIATE 的 本 地 动态 SQL 与 使 用 隐 式 游标 的 静态 SQL 类 似 
换 句 话说 ， 它 不 能 控制 游标 的 生命 周期 。 下 面 的 PL/SQL 代 码 块 实现 了 测试 案例 2: 
DECLARE 
1 pad VARCHAR2(4000); 
BEGIN 
FOR i IN 1..10000 
LOOP 


EXECUTE IMMEDIATE 'SELECT pad FROM t WHERE val = :1' INTO 1 pad USING ii 
END LOOP; 
END; 


没有 了 对 游标 的 控制 ,不 可 能 写 出 实现 测试 案例 3 的 代码 。 出 于 这 个 原因 ， 可 以 像 静 态 SQL 那 样 
使 用 客户 端 游标 缓存 。 


3. 本 地 动态 SQL: OPEN/FETCH/CLOSE 
从 游标 管理 的 角度 来 看 ， 基 于 0PENMMFETCH/CLOSE 的 本 地 动态 SQL 与 使 用 隐 式 游标 的 静态 SQL 类 似 。 
换 句 话说 ， 它 仅 能 控制 提取 ( FETCH ) 阶段 。 下 面 的 PL/SQL 代 码 块 实现 了 测试 案例 2 
DECLARE 
TYPE t cursor IS REF CURSOR; 
1 cursor t cursor; 
1 _pad VARCHAR2(4000); 
BEGIN 
FOR i IN 1..10000 
LOOP 
OPEN 1 cursor FOR “SELECT pad FROM 七 WHERE Ul = 下 NG 
FETCH 1 cursor INTO 1 pad; 
CLOSE 1 _CUTSOT; 
END LOOP; 
END; 


没有 对 游标 的 完全 控制 ， 不 可 能 写 出 实现 测试 案例 3 的 人 代码。 此外， 使 用 基于 OPEN/FETCH/CLOSE 的 
动态 SQL， 数 据 库 引 擎 无 法 利用 客户 端 语 句 缓 存 。 这 意味 着 要 解决 这 种 代码 引起 的 解析 问题 的 唯一 途 
径 ， 是 使 用 EXECUTE IMMEDIATE 或 dbms_sq] 包 对 语句 进行 改写 。 作 为 一 种 变通 方案 ， 还 可 以 考虑 服务 天 
端 语句 缓存 。 


4. 本 地 动态 SQL: dbms_sql 包 


dbms_sql 包 提供 对 游标 的 生命 周期 的 完全 控制 。 在 下 面 的 PL/SQL 代 码 块 中 ( 测试 案例 2 )， 请 注意 
显 式 编码 的 每 一 步 : 


DECLARE 
1 cursor INTEGER; 
1 pad VARCHAR2(4000); 
1 retval INTEGER; 
BEGIN 
FOR i IN 1..10000 
LOOP 
1 cursor := dbms sql.open_cursor; 
dbms_sql.parse(l cursor, "SELECT pad FROM 七 WHERE val = :1', 1); 
dbms_sql.define column(1 cursor, 1, 1 pad, 10); 


12.4 使 用 应 用 编程 接口 395 


dbms_sql.bind variable(] cursor, ':1', i); 
1 retval := dbms sql.execute(l] cursor); 
IF dbms sql.fetch rows(l cursor) > 0 
THEN 
NULL; 

END IF; 
dbms_sql.close cursor(] cursor); 

END LOOP; 

END; 


因为 可 以 完全 控制 游标 , 实现 测试 案例 3 就 没有 问题 了 ,下面 的 PL/SQL 代 码 块 展示 了 这 样 的 例子 。 
注意 ， 为 了 避免 不 必要 的 软 解析 ， 准备 游标 ( open_cursor 、parse 、define_column ) 和 关闭 游标 
( close_cursor ) 的 过 程 被 放置 到 循环 外 。 


DECLARE 
1 cursor INTEGER; 
1 pad VARCHAR2(4000); 
1 retval INTEGER; 
BEGIN 
1 cursor := dbms sql.open cursor; 
dbms_sql,parse(1 cursor, "SELECT pad FROM 七 WHERE val = :1', 1); 
dbms_ sql.define_column(1_ cursor, 1, 1 pad, 10); 
FOR i IN 1..10000 
LOOP 
dbms_sql.bind variable(1 cursor, ':1', i); 
1 retval := dbms sql.execute(l] cursor); 
IF dbms sql.fetch rows(l] cursor) > 0 
THEN 
NULL; 
END IF; 
END LOOP; 
dbms_sql.close cursor(] cursor); 
END; 


使 用 dbms_sql 包 时 ， 数 据 库 引 擎 无 法 利用 客户 端 语句 缓存 。 所 以 ， 为 了 优化 一 个 有 太 多 软 解析 的 
应 用 程序 ( 如 测试 案例 2 )， 必 须 修改 它 以 重用 游标 如 测试 案例 3 )。 作 为 一 个 权 宣 方案 ， 可 以 考虑 服 
务 器 端 语句 缓存 。 


pa 


12.4.2 OCI 


OCI 是 一 种 低级 别 的 应 用 编程 接口 。 因 此 ， 它 可 以 提供 对 游标 生命 周期 的 完全 控制 。 例 如 ， 在 下 
面 的 代码 段 中 ， 实 现 了 测试 案例 2， 请 注意 显 式 编码 的 步骤 : 
for (i=1 ; i<=10000 ; i++) 
{ 
OCIStmtPrepare2(svc, (OCIStmt **)&stm, err, sql, strlen(sql), NULL, 0, OCIT NTV_SYNTAX, 
OCI_DEFAULT ) ; 
OCIDefineByPos(stm, &def, err, 1, val, sizeof(val), SQLT STR, 0, 0, 0, OCI DEFAULT); 
OCIBindByPos(stm, &bnd, err, 1, &i, sizeof(i), SQLT INT, 0, 0, 0, 0, 0, OCT DEFAULT); 
OCIStmtExecute(svc, stm, err, 0, 0, 0, 0, OCIT DEFAULT); 
if (r = OCIStmtFetch2(stm, err, 1, OCT FETCH NEXT, 0, OCT DEFAULT) == OCI SUCCESS) 


// 对 数据 进行 某 些 处 理 
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} 
OCIStmtRelease(stm, err, NULL, 0, OCI DEFAULT); 
} 


既然 可 以 对 游标 进行 完全 控制 ， 也 就 可 以 实现 测试 案例 3。 下 面 的 代码 片段 就 是 一 个 例子 。 注 意 ， 
为 了 避免 不 必要 的 软 解析 ， 准 备 游标 ( 0CIStmtPrepare2 和 0CIDefineByPos ) 和 关闭 游标 ( 0CIStm- 
tRelease ) 的 函数 被 放置 到 循环 外 。 


OCIStmtPrepare2(svc, (OCIStmt **)&stm, err, sql, strlen(sql), NULL, 0, OCI NTV_SYNTAX， 
OCI_ DEFAULT); 

OCIDefineByPos(stm, &def, err, 1, val, sizeof(val), SQLT _ STR, 0, 0, 0, OCI DEFAULT); 

for (i=1 ; i<=10000 ; i++) 


OCIBindByPos(stm, &bnd, err, 1, &i, sizeof(i), SQLT_INT, 0, 0, 0, 0, 0, OCI DEFAULT); 
OCIStmtExecute(sve, stm, err, 0, 0, 0, 0, OCI DEFAULT); 
if (r = OCIStmtFetch2(stm, err, 1, OCT FETCH NEXT, 0, OCI DEFAULT) == OCI SUCCESS) 


{ 
// 对 数据 进行 某 些 处 理 
} 


OCIStmtRelease(stm, err, NULL, 0, OCI DEFAULT) ; 

OCI 不 仅 启 用 对 游标 的 完全 控制 ， 而 且 还 支持 客户 端 语 句 缓存 。 要 使 用 它 ， 仅 需 启 用 语句 缓存 并 
使 用 OCIStmtPrepare2 和 0CIStmtRelease 函 数 (如 上 面 的 例子 那样 )。 调用 0OCIStmtRelease 函 数 时 ， 会 将 
游标 添加 到 缓存 中 。 人 然后 ,通过 0CIStmtPrepare2 函 数 创建 新 的 游标 时 、 就 会 访问 缓存 以 查找 是 否 有 一 
条 拥有 相同 文本 的 SQL 语句 在 其 中 。 

局 用 语句 缓存 的 方法 有 多 种 。 基 本 上 ， 只 需要 在 会 话 打开 或 从 一 个 池 中 恢复 时 指定 它 就 可 以 。 例 
如 ， 如 果 通 过 0CILogon2 函 数 打开 一 个 没有 保存 到 池 中 的 会 话 ， 有 必要 指定 0CI_LOGON2_STMTCACHE 这 个 
值 来 启用 这 种 模式 。 


OCILogon2(env, err, &svc, username, strlen(username), password, strlen(password), 
dbname, strlen(dbname), OCI_LOGON2 STMTCACHE) 


默认 情况 下 ， 缓 存 的 大 小 是 20。 下 面 的 代码 片段 展示 如 何 通 过 设置 服务 上 下 文 上 的 0CI ATTR_ 
STMTCACHESIZE 属 性 ， 将 缓存 的 大 小 更 改 为 50。 注 意 ， 将 这 个 属性 设置 为 0 会 禁用 语句 缓存 。 


ub4 size = 50; 
OCIAttrSet(svc, OCI HTYPE SVCCTX, &size, 0, OCI ATTR_STMTCACHESIZE, err); 


本 节 中 提供 的 C 代 码 的 例子 分 别 摘录 自 实现 了 测试 案例 1、2 和 3 的 ParsingTest1.c、 ParsingTest2.c 
以 及 ParsingTest3.c 的 文件 。 


12.4.3 JDBC 


java.sql.Statement 是 由 JDBC 提 供 的 执行 SQL 语 句 的 基础 类 。 如 表 12-1 所 示 ， 使 用 它 时 出 现 解 析 
问题 并 非 不 可 能 。 事 实 上 ， 它 不 支持 绑 定 变量 、 游 标的 重用 以 及 客户 端 语句 缓存 。 基 本 上 ， 使 用 它 仅 
可 能 实现 测试 案例 1。 下 面 的 代码 片段 进行 了 示范 : 

sql = "SELECT pad FROM t WHERE val = "; 

for (int i=0 ; i<10000; i++) 


t 
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statement = connection.createStatement(); 
resultset = statement.executeQuery(sql + Integer.toString(i)); 
if (resultset.next()) 


pad = resultset.getString("pad"); 


resultset.close(); 
statement.close(); 


J 

为 了 避免 由 上 面 的 代码 片段 执行 所 产生 的 硬 解析 , 必须 使 用 java.sql.PreparedStatement 类 (或 者 
它 的 一 个 子 类 )， 它 是 java.sql.5tatement 的 子 类 。 下 面 的 代码 片段 展示 了 使 用 它 实 现 测试 案例 2。 注 
意 , 用 于 查找 的 值 是 通过 绑 定 变量 定义 的 (在 Java 中 使 用 一 个 问号 定义 并 称 作 占 位 符 ), 而 不 是 循环 传 
递 给 sql 变 量 ( 如 上 面 例子 那样 )。 


sql = "SELECT pad FROM t WHERE val = ?"; 
for (int i=0 ; i<10000; i++) 
{ 
statement = connection.prepareStatement(sql); 
statement.setInt(1, i); 
resultset = statement.executeQuery(); 
if (resultset.next()) 
{ 
pad = resultset.getString("pad"); 
} 
resultset.close(); 
statement.close(); 


} 
接 下 来 的 改进 还 要 避免 软 解 析 ， 换 言 之 ， 实 现 测试 案例 3。 如 下 面 的 代码 片段 所 示 ， 可 以 通过 将 
创建 和 关闭 预 编译 语句 的 代码 移动 到 循环 外 面 来 实现 这 个 目标 : 


sql = "SELECT pad FROM t WHERE val = ?"; 
statement = connection.prepareStatement(sq]); 
for (int i=0 ; ix10000; i++) 
{ 

statement.setInt(1, i); 

resultset = statement.executeQuery(); 

if (resultset.next()) 

{ 

pad = resultset.getString("pad"); 


resultset.close(); 


statement.close(); 

Oracle JDBC 驱 动 程序 提供 两 个 用 于 支持 客户 端 语句 缓存 的 扩展 : 隐 式 和 显 式 语句 缓存 。 如 名 称 所 
示 ， 前 者 几乎 不 需要 代码 的 变更 ， 后 者 必须 显 式 实现 。 

通过 显 式 语 名 缓存， 语句 依靠 Oracle 定 义 的 方法 来 打开 和 关闭 。 鉴 于 这 对 代码 有 巨大 的 影响 ， 并 
日 与 隐 式 语句 缓存 相 比 ， 编 写 更 快 的 代码 会 变 得 更 困难 。 想 了 解 更 多 信息 ， 请 参考 JDBC Developer”s 
Guide 手 册 。 
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通过 隐 式 语句 缓存 ， 当 调用 close 方 法 时 ， 会 将 预 编译 的 语句 添加 到 缓存 中 。 然 后 ， 当 一 条 新 的 
预 编译 语句 通过 prepareStatement 方 法 进行 实例 化 时 ， 就 会 检查 缓存 以 查 明 是 否 拥有 相同 文本 的 游标 
已 经 存在 于 其 中 。 


注意 只 有 实现 了 java.sq1.PreparedStatement 和 java.sql.CallableSstatement 接 口 的 类 才 支 持 隐 式 
语句 缓存 。 换 和 句 话说 ， 普 通 的 语句 (基于 java.sql1.Statement ) 不 支持 隐 式 语句 缓存 


下 面 的 代码 行 展 示 了 在 会 话 级 别 上 启用 隐 式 语句 缓存 。 小 心 : 需要 将 缓存 的 大 小 设置 为 一 个 大 于 
0 的 值 。 因 为 这 两 个 方法 都 是 Oracle 的 扩展 程序 : 
((oracle.jdbc.OracleConnection)connection).setImplicitCachingEnabled(true); 
((oracle.jdbc.OracleConnection)connection).setStatementCacheSize(50); 
男 一 种 启用 隐 式 语句 缓存 的 方式 是 通过 0racleDataSource 类 的 setImplicitCachingEnabled 和 
setMaxStatements 方 法 。 但 是 需要 注意 ，setMaxStatements 方 法 已 被 弃 用 。 
默认 情况 下 ， 所 有 预 编 译 的 语句 都 通过 隐 式 语句 缓存 被 缓存 起 来 。 当 缓存 占 满 时 ， 最 近 最 少 使 用 
的 那 一 个 就 会 关闭 并 被 一 个 新 的 取代 。 如 果 有 必要 , 可 以 禁用 特定 语句 的 缓存 。 下 面 的 代码 举例 说 明 : 
((oracle.jdbc.OraclepreparedStatement)statement).setDisableSstmtCaching(true); 
本 节 中 作为 例子 的 Java 代 码 摘 录 自 分 别 实现 了 测试 案例 1 、2 和 3 的 ParsingTest1.java、 
ParsingTest2.java 以 及 ParsingTest3.java 文 件 。 


12.4.4 ODP.NET 


ODPNET 提 供 对 游标 生命 周期 的 少量 控制 。 在 下 面 实现 测 试 案例 1 的 代码 片段 中 ，ExecuteReader 
方法 在 同一 时 间 触 发 解析 、 执 行 和 提取 调用 : 
Sql = "SELECT pad FROM 七 WHERE val = "; 
command = new OracleCommand(sql, connection); 
for (int 1 = 0 1 «< 10000: i4+) 
{ 
command.CommandText = Sql + i; 
reader = command.ExecuteReader(); 
if (reader.Read()) 


pad = reader[0].ToString(); 


reader.Close(); 

} 

为 避免 上 面 的 代码 片段 执行 所 产生 的 全 部 人 硬 解 析 ，0racleParameter 类 必须 用 于 传递 参数 ( 绑 定 变 
量 )。 下面 的 代码 片段 展示 了 使 用 它 来 实现 测试 案例 2。 注 意 ， 用 于 查找 的 值 是 通过 参数 定义 的 ， 而 不 
是 循环 传递 给 sql 变 量 ( 如 上 面 例子 那样 )。 

String sql = "SELECT pad FROM t WHERE val = :val"; 

OracleCommand command = new OracleCommand(sql, connection); 

OracleParameter parameter = new OracleParameter("val", OracleDbType.Int32); 


command.Parameters .Add(parameter); 
OracleDataReader reader; 
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for (int i = 0; i «< 10000; i++) 
{ 
parameter.Value = Convert.ToInt32(i); 
reader = command.ExecuteReader(); 
if (reader.Read()) 
{ 
pad = reader[0].ToString(); 
} 


reader.Close(); 


} 
使 用 ODPNET， 不 可 能 实现 测试 案例 3。 但 是 ， 要 达到 同样 的 效果 ， 可 以 使 用 客户 端 语句 缓存 。 
有 两 种 方法 来 启用 它 并 设置 缓存 的 大 小 。 第 一 种 ,为 所 有 控制 语句 缓存 并 使 用 特定 Oracle home 的 应 用 
程序 ， 在 注册 表 中 设置 下 面 的 值 。 如 果 设 置 为 0， 会 禁用 语句 缓存 。 如 果 设 置 为 其 他 值 ， 则 会 启用 语 
名 缓存 ， 并 且 这 个 值 指定 缓存 的 大 小 (<Assembly Version> 是 Oracle.DataAccess.dl1 的 完整 版 本 号 )。 
HKEY LOCAL MACHINE\SOFTWARE\ORACLE\ODP.NET\<Assembly Version>\StatementCacheSize 
第 二 种 方法 是 直接 在 代码 中 通过 0racleConnection 类 提供 的 Statement Cache Size 属 性 控制 语句 组 
存 。 基 本 上 ， 它 扮演 的 角色 与 注册 表 是 一 样 的， 不 过 只 针对 一 个 单独 的 连接 。 下面 的 代码 片段 展示 了 
启用 语句 缓存 并 将 其 大 小 设置 为 10: 
String connectString = "User Id=" + USe + 
";Password=" + password + 
"”;Data Source=" + dataSource + 


";Statement Cache Size=10"; 
OracleConnection connection = new OracleConnection(connectSstring); 


注意 ,在 会 话 级 别 上 的 设置 会 覆盖 注册 表 中 的 设置 。 此 外 ， 当 启用 语句 缓存 时 ， 可 以 在 命令 行 级 
别 上 通过 将 AddTostatementCache 属 性 设置 为 false 来 禁用 它 。 

本 节 中 作为 例子 的 C# 代 码 分 别 摘录 自 实现 了 测试 案例 1 和 2 的 Pars ingTest1.cs 和 ParsingTest2.cs 
区 伴 。 


12.4.5 PHP 


在 PHP 中 ，PECL OCI8 扩 展 提供 了 对 游标 生命 周期 的 完全 控制 。 例 如 ， 在 下 面 实 现 了 测试 案例 2 
的 代码 片段 中 ,请 注意 显 式 编码 的 步 又 : 
$sql = "SELECT pad FROM t WHERE val = :val"; 
for ($i = 1; $i <= 10000; $i++) 
{ 
$statement = oci parse($connection, $sq1); 
oci bind by name($statement, ":val", $i, -1, SQLT_INT); 
oci execute($statement, OCI NO AUTO COMMIT); 
if ($row = oci fetch assoc($statement)) 


$pad = $row[ 'PAD']; 


oci free statement($statement); 


} 
既然 可 以 完全 控制 游标 ， 也 就 可 以 实现 测试 案例 3 了 。 下 面 的 代码 片段 会 举例 说 明 。 请 注意 , 为 
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了 避免 不 必要 的 软 解析 ， 将 准备 游标 ( oci parse 和 oci bind by name ) 和 关闭 游标 ( oci free_ 
statement ) 的 函数 放置 在 了 循环 外 面 。 


$sql = "SELECT pad FROM t WHERE val = :val"; 
$statement = oci parse($connection, $5ql1); 

oci bind by name($statement, ":val", $i, -1, SQLT_INT); 
for ($i = 1; $i <= 10000; $i++) 


oci execute($statement, OCT NO_AUTO COMMIT); 
if ($row = oci fetch assoc($statement)) 


$pad = $row['PAD’]; 


} 


oci free statement($statement); 

PHP 不 仅 可 以 完全 控制 游标 ， 而 且 从 OCI8 1.1 开 始 ， 还 支持 客户 端 语句 缓存 。 要 使 用 它 ， 可 以 使 
用 oci8.statement_cache_size 指 令 。 大 于 0 的 值 会 启用 客户 端 语句 缓存 , 并 指定 缓存 游标 个 数 。 默认 值 
是 20， 人 允许 客户 端 最 多 缓存 20 个 游标 。 要 更 改 这 个 值 ， 请 在 php.ini 配 置 文件 中 添加 类 似 以 下 的 内 容 : 

oci8.statement cache size = 50 

本 节 中 作为 例子 使 用 的 PHP 代 码 摘录 自 ParsingTest1.php、ParsingTest2.php 以 及 ParsingTest3. 
php 文 件 。 这 些 文件 分 别 实现 了 测试 案例 1 、2 和 3。 


12.5 小结 


本 章 描述 如 何 识别 、 解 决 以 及 避 开 解析 问题 & 核心 内 容 是 ,通过 了 解 应 用 程序 的 工作 原理 以 及 利 
用 应 用 编程 接口 ， 从 而 能 够 通过 在 开发 阶段 编写 高 效 代码 来 避免 解析 问题 。 

鉴于 在 一 个 游标 的 生命 周期 中 ， 执 行 阶段 紧 跟 着 SQL 语句 的 解析 和 变量 的 绑 定 ， 有 必要 了 解数 据 
库 引 擎 访问 数据 时 使 用 的 技术 。 下 一 章 会 讨论 这 方面 的 内 容 ， 并 描述 如 何 利 用 不 同类 型 的 索引 以 及 分 
区 方法 ， 以 便 帮 助 加 速 SQL 语 句 的 执行 。 
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就 像 第 10 章 描述 的 那样 ， 执 行 计划 是 由 多 个 操作 组 成 的 。 最 常 使 用 的 操作 是 访问 、 过 滤 和 转换 数 
据 。 本 童 主要 涉及 数据 访问 操作 ， 也 就 是 ， 数 据 库 引擎 能 够 访问 数据 的 方式 。 

基本 上 在 一 张 表 中 定位 数据 的 方式 仅 有 两 种 。 第 一 ， 是 扫描 整 张 表 。 第 二 ， 是 基于 额外 的 访问 结 
构 ( 比如 索引 ) 或 包含 表 本 身 ( 比如 散 列 群集 ) 的 结构 来 进行 查找 。 此 外 ， 在 分 区 情况 下 ,会 将 访问 
限制 到 分 区 的 一 个 子 集 。 这 与 在 本 书 中 寻找 特定 信息 没有 区 别 ,。 要 么 读 完整 本 书 , 要 么 阅读 单独 一 章 ， 
或 者 使 用 索引 或 内 容 表 来 找 出 想 要 的 信息 。 

本 章 的 第 一 部 分 将 描述 ， 通 过 看 SQL 跟踪 或 动态 性 能 视图 提供 的 运行 时 统计 信息 来 识别 低 效 的 访 
问 路 径 。 第 二 部 分 介绍 可 用 的 访问 方法 和 使 用 它们 的 场合 。 对 于 每 个 访问 路 径 ， 也 会 介绍 可 以 用 来 复 
制 的 hint 和 与 它 相关 的 执行 计划 操作 。 


注意 ”本章 多 个 SQL 语句 包含 hint。 我 这 么 做 不 光 是 要 向 你 展示 hint 对 应 的 访问 路 径 ， 同 时 也 举例 说 
明 它 们 的 使 用 。 总 之 ， 提 供 的 既 不 是 真实 的 引用 也 不 是 完整 的 语法 。 可 以 在 SOL Reference 手 
册 的 第 2 章 中 找到 相关 信息 。 
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第 10 章 介绍 了 通过 查看 查询 优化 器 的 估 值 和 正确 识别 的 限制 ， 判 断 执 行 计 划 是 否 高 效 的 方法 。 重 
点 需要 明白 即使 查询 优化 器 正确 选择 了 最 优 的 执行 计划 ， 并 不 代表 这 个 执行 计划 就 会 高 效 执行 。 也 许 
在 修改 了 SQL 语句 或 访问 结构 ( 例如 ， 增 加 索引 ) 之 后 ， 会 想到 更 好 的 执行 计划 。 在 接 下 来 的 几 部 分 
中 ,会 介绍 用 来 帮助 识别 低 效 访问 路 径 时 可 以 执行 的 额外 检查 ， 以 及 导致 访问 路 径 低 效 的 原因 和 避免 
的 方法 。 


13.1.1 识别 
最 有 效 的 访问 路 径 是 能 够 使 用 最 少 的 资源 来 处 理 数据 。 因 此 ， 要 识别 访问 路 径 是 否 高 效 ， 可 以 识 
别 它 处 理 使 用 的 资源 数 是 否 可 以 接受 。 要 做 到 这 些 , 需要 定义 如 何 衡量 资源 的 使 用 ， 以 及 怎样 才 算 是 


可 以 接受 。 此 外 ， 还 需要 考虑 检查 的 可 行 性 。 换 句 话 说， 也 需要 考虑 执行 检查 需要 做 多 少 工作 。 它 必 
须 尽 可 能 简单 。 实 际 上 ,完善 的 检查 需要 花费 太 多 的 时 间 去 执行 ， 在 实际 中 这 是 无 法 接受 的 ， 尤 其 是 
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需要 处 理 数 十 甚至 数 百 条 等 待 优化 的 SQL 语句 ， 或 者 仅仅 是 因为 你 工作 的 时 间 很 紧 。 

作为 附注 ， 请 记得 本 节 关 注 的 是 效率 ,不 仅仅 是 速度 。 重 点 需要 知道 往往 最 高 效 的 访问 路 径 并 不 
是 最 快 的 。 正 如 第 1$ 章 所 述 ， 使 用 并 行 处 理 时 ， 有 时 即使 使 用 的 资源 更 多 ， 但 也 可 以 获得 更 好 的 响应 
时 间 。 当 然 ， 当 你 考虑 整个 系统 时 ，SQL 语 句 使 用 越 少 的 资源 ( 换 句 话说 ， 效 率 更 高 )， 系 统 的 扩展 
性 就 会 越 高 ， 速 度 越 快 。 这 是 因为 很 显然 资源 是 有 限 的 。 

作为 第 一 近似 值 ， 当 访问 路 径 使 用 的 资源 数 与 返回 行 数 ( 即 ， 返 回执 行 计划 里 父 操 作 的 行 数 ) 成 
正比 时 , 是 可 接受 的 。 换 名 话说 ， 当 返回 少量 的 行 , 那么 预期 的 资源 使 用 率 会 降低 ， 而 返回 大 量 行 时 ， 
资源 使 用 率 会 升 高 。 因 此 ， 检 查 应 该 基于 返回 单行 时 的 资源 使 用 数 。 

理想 情况 下 ， 你 会 衡量 数据 库 引 擎 使 用 的 全 部 四 种 资源 类 型 (CPU 、 内 存 、 磁 盘 和 网 络 ) 的 消耗 。 
当然 ， 这 可 以 做 到 ， 但 不 幸 的 是 ， 获 取 所 有 这 些 指标 会 花费 很 多 时 间 和 精力 ， 并且 通常 也 只 对 优化 会 
话 中 一 小 部 分 的 SQL 语句 有 效 。 你 也 应 该 考虑 当 处 理 一 行 时 ，CPU 处 理 时 间 是 依赖 处 理 器 的 速度 的 ， 
这 在 系统 与 系统 之 间 会 有 明显 的 不 同 。 进 一 步 讲 ， 内 存 使 用 的 总 数 几 乎 与 返回 行 数 成 正比 ， 而 磁盘 和 
网 络 并 不 是 总 会 用 到 。 实 际 上 ， 长 时 间 运 行 的 SQL 语 句 使 用 适度 的 内 存量 并 上 且 没有 磁盘 或 网 络 访问 也 
不 是 罕见 的 。 

幸运 的 是 ， 有 一 个 数据 库 度 量 很 容易 收集 到 ， 它 可 以 告诉 你 很 多 数据 库 引擎 工作 的 信息 : 风 辑 读 
数 ， 即 ,在 SQL 语句 执行 期 间 访问 的 块 数 。 对 于 它 来 说 有 五 个 好 处 。 第 一 ， 导 辑 读 是 CPU-bound 操 作 ， 
因此 可 以 很 好 地 反映 CPU 使 用 率 。 第 二 ， 或 许 逻 辑 读 会 导致 物理 读 ， 因 此 如 果 减 少 逻辑 读数 ， 也 可 能 
会 减少 磁盘 IO 操作 。 第 三 ,逻辑 读 是 序列 化 操作 。 由 于 你 经 常 需要 优化 多 用 户 负载 , 最 小 化 滥 辑 读 可 
以 很 好 地 避免 扩展 性 问题 。 第 四 ， 在 SQL 语句 和 执行 计划 操作 级 别 上 ， 逻 辑 读数 在 SQL 跟踪 文件 和 动 
态 性 能 试图 中 是 现成 的 。 第 五 ， 风 辑 读数 独立 于 CPU 和 磁盘 1/0 子 系统 的 负载 。 

由 于 逻辑 读数 很 接近 整体 的 资源 消耗 数 ， 因 此 你 可 以 主要 处 理 ( 至 少 在 第 一 轮 优化 中 ) 返回 的 行 
中 有 较 高 逻辑 读数 的 访问 路 径 。 下 面 是 一 些 通 常 认为 好 的 “经 验 法 则 ”。 

口 每 行 小 于 $ 个 逻辑 读 的 访问 路 径 基 本 上 是 好 的 。 

口 每 行 最 多 10~15 个 逻辑 读 的 访问 路 径 基本 上 可 以 接受 。 

口 通常 认为 每 行 超 过 20 个 逻辑 读 的 访问 路 径 是 低 效 的 。 换 名 话说 ， 可 能 有 提升 的 空间 

要 检查 每 行 的 逻辑 读数 ， 通 常 有 两 种 方法 。 第 一 ， 利 用 动态 性 能 视图 提供 的 执行 统计 信息 ， 然 后 
通过 dbms_xplan 包 来 显示 (第 10 章 已 详细 介绍 过 该 技术 ), 下 面 的 执行 计划 是 使 用 这 种 方法 生成 的 . 对 
于 每 个 操作 ， 你 能 看 到 返回 的 行 数 (A-Rows 列 ) 和 为 了 返回 行 执行 的 逻辑 读数 ( buffer 列 ) : 

SELECT * FROM 七 WHERE n1 BETWEEN 6000 AND 7000 AND n2 = 19 


| Id | Operation | Name | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 3 | 28 | 
|* 1 | TABLE ACCESS BY INDEX ROWID| T | 3 | 28 | 
|* 2 | INDEX RANGE SCAN |TN2I| 24| 4 | 


1 - filter(("N1">=6000 AND "N1"<=7000)) 
2 - access("N2"=19) 


第 二 种 方法 是 利用 SQL 跟踪 提供 的 信息 ( 第 3 章 已 经 详细 介绍 过 该 技术 )。 以 下 代码 段 引 用 自 
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TKPROF 生 成 的 输出 ,使 用 的 是 与 上 一 个 例子 相同 的 查询 。 请 注意 ,返回 行 数 ( Row 列 ) 和 逮 辑 读 ( cr 
属性 ) 与 之 前 的 指标 吻合 。 


Rows Row Source Operation 


3 TABLE ACCESS BY INDEX ROWID T (cr=28 pr=0 pw=0 time=80 us) 
24 INDEX RANGE SCAN T N2 I (cr=4 pr=0 pw=0 time=25 Us)(object id 39684) 


基于 之 前 提 到 的 经 验 法 则 ， 可 以 接受 这 样 的 执行 计划 作为 例子 来 使 用 。 实 际 上 ,， 访问 路 径 返 回 的 
每 行 逻辑 读数 大 约 是 9 ( 28/3 )。 让 我 们 来 看 看 同样 的 SQL 语句 执行 计划 糟糕 时 是 什么 样子 。 请 注意 ， 
糟糕 是 因为 访问 路 径 返 回 的 每 行 逻辑 读数 是 130 ( 390/3 )， 并 不 是 因为 它 包 含 全 表 扫 描 ! 


| Id | 0peration | Name | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 3 | 390 | 
|* 1 | TABLE ACCESS FULLIT | 3 | 390 | 


1 - filter(("N2"=19 AND "N1">=6000 AND "N1"<=7000)) 

需要 青 次 强调 本 节 是 关于 访问 路 径 的 a 因此 ， 你 必须 仅 在 访问 路 径 层 面 考虑 这 些 指 标 ， 而 不 是 针 
对 整个 SQL 语 句 。 实 际 上 ， 在 SQL 语 句 级 别 上 这 些 指标 或 许 会 造成 误导 。 要 理解 可 能 发 生 的 问题 ， 让 
我 们 来 检查 以 下 查询 。 如 果 是 在 SQL 语句 级 别 ( 大 概 是 操作 0 ) 上 ， 那 么 执行 了 387 逻 辑 读 来 返回 一 行 
数据 。 换 句 话 说， 这 会 导致 错误 地 将 其 归 类 为 低 效 的 。 然 而 ， 如 果 访 问 操作 的 指标 〈 操作 2 ) 正确 列 
和 人 考虑 范围 内 ， 那么 逻辑 读数 (387 ) 和 返回 行 数 ( 160 ) 的 比率 ， 会 将 这 个 访问 路 径 归 类 为 高 效 的 。 
本 例 中 的 问题 是 操作 1 对 操作 2 返回 的 行使 用 sum 函 数 。 结 果 ， 它 永远 都 只 会 返回 单行 并 且 “ 隐 藏 ”了 
访问 路 径 的 性 能 指标 : 

SELECT sum(n1) FROM t WHERE n2 > 246 


| Id | Operation | Name | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | | 387 | 
| 1| SORT AGGREGATE | | 1 | 387 | 
|* 2 | TABLE ACCESS FULL| T | 160 | 387 | 


2 - filter("N2">246) 
如 果 你 真 的 只 能 看 SQL 语句 级 别 的 指标 ( 例如 , 由 于 SQL 跟踪 文件 不 包含 执行 计划 ), 那么 使 用 之 
前 提供 的 经 验 法 会 变 得 很 困难 ， 仅 仅 因为 你 没有 足够 的 信息 。 然 而 ,在 这 种 情况 下 ， 至 少 对 于 简单 的 
SQL 语句 来 说 ， 可 以 尝试 猜测 访问 路 径 指 标 而 适应 经 验 法 则 。 比 如 ， 可 以 仔细 检查 SQL 语句 是 否 存在 
聚合 ， 找 出 SQL 语句 中 引用 了 多 少 张 表 ， 然 后 对 应 引用 表 的 数量 ， 按 比例 增加 经 验 法 则 中 的 限制 。 


13.1.2 误区 
检查 逻辑 读数 时 , 必须 注意 两 个 会 曲解 指标 的 误区 。 第 一 个 与 一 致 读 有 关 , 第 二 个 与 行 预 取 有 关 。 
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1. 一 致 读 

对 于 每 一 条 SQL 语 句 ， 数 据 库 引擎 都 会 保证 处 理 数据 的 一 致 性 。 为 了 达到 这 个 目的 ， 数据 块 的 一 
致 性 副本 会 基于 当前 数据 块 和 回 深 块 在 运行 时 创建 。 要 执行 这 样 的 操作 需要 完成 数 个 逻辑 读 。 因 此 ， 
访问 路 径 操作 执行 的 逻辑 读数 非常 依赖 于 需要 重建 的 块 数 。 以 下 代码 引用 自 read_consistency.sql 脚 
本 生成 的 输出 。 请 注意 使 用 的 查询 与 上 节 相 同 。 根 据 执行 统计 信息 ， 会 返回 相同 的 行 数 (实际 上 返回 
相同 的 数据 )。 然 而 ， 它 会 执行 更 多 的 逻辑 读 ( 相 比 28， 一 共 执 行 了 354 )。 会 造成 这 个 影响 是 因为 修 
改 了 数据 块 的 另 一 个 会 话 需要 执行 该 查询 。 由 于 在 查询 开始 时 修改 并 未 提交 ， 数 据 库 引擎 就 必须 重建 
这 些 块 。 这 会 导致 更 高 的 逻辑 读 : 

SELECT * FROM t WHERE n1 BETWEEN 6000 AND 7000 AND n2 = 19 


| Id | Operation | Name | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 3 | 354 | 
|* 1 | TABLE ACCESS BY INDEX ROWID| T | 3 | 354 | 
|* 2 | INDEX RANGE SCAN | TN2I | 24 | 139 | 


1 - filter(("N1">=6000 AND "N1"<=7000)) 
2 - access("N2"=19) 


2. 行 预 取 
从 优化 的 角度 来 看 ， 应 该 避免 基于 行 的 处 理 。 例 如 ， 当 客户 端 从 数据 库 取 回 数据 时 ， 它 可 以 逐 行 
取 回 ， 或 者 更 好 些 ， 一 次 取 回 多 行 。 这 个 技术 ， 被 称 为 行 预 取 ( row prefetching )， 会 在 第 15 章 中 详细 
介绍 。 现 在 ， 让 我 们 只 看 它 对 逻辑 读数 的 影响 。 简 单 地 说 ， 每 当 数据 库 引 警 访问 一 个 块 ， 逻 辑 读 就 会 
计数 一 次 。 针 对 全 表 扫 描 ， 会 有 两 个 极端 。 如 果 将 行 预 取 设 置 为 !， 返回 每 行 大 约 一 个 逻辑 读 。 如 果 
将 行 预 取 设 置 为 大 于 每 个 表 块 中 存储 的 行 数 ,那么 逻辑 读 就 接近 表 的 块 数 。 以 下 代码 引用 自 
row_prefetching.sql 肢 本 生成 的 输出 。 在 第 一 个 执行 中 , 行 预 取 设置 为 2 ( 这 个 值 的 选择 会 在 15.5 节 中 
介绍 )， 逻 辑 读数 ( 5388 ) 大 约 是 行 数 ( 10 000 ) 的 一 半 。 在 第 二 个 执行 中 ， 由 于 行 预 取 数 ( 100 ) 高 
“于 每 个 块 的 平均 行 数 ( 25 )， 人 逻辑 读数 ( 488 ) 大 约 等 于 块 数 ( 401 ): 
SOL> SELECT num rows, blocks, round(num rows/blocks) AS Tows_per_block 
2 FROM user tables 
3 WHERE table name = 'T'; 
NUM ROWS BLOCKS ROWS PER BLOCK 


SOL> set arraysize 2 


SQL> SELECT * FROM t; 


| 0 | SELECT STATEMENT | | 10000 | 5388 | 
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| 1| TABLE ACCESS FULLIT | 10000 | 5388 | 


| Id | Operation | Name | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 10000 | 488 | 
| 1| TABLE ACCESS FULL| T | 10000 | 488 | 


注意 在 SQL*Plus 中 ， 通 过 arraysize 系 统 变 量 管理 行 预 取 数 。 默 认 值 是 15。 


考虑 到 行 预 取 对 逻辑 读数 的 依赖 , 每 当 出 于 测试 目的 使 用 诸如 SQL*Plus 之 类 的 工具 执行 SQL 语 句 
时 , 都 应 该 仔细 将 行 预 取 值 设置 得 与 应 用 一 致 。 换 句 话说 , 用 来 测试 的 工具 预 取 的 行 数 应 与 应 用 一 致 。 
如 果 不 这 样 做 ,会 导致 很 多 错误 的 结果 。 

当 执行 的 操作 被 阻塞 时 ( 例如 ， 聚 合 操作 )，SQL 引 擎 会 在 内 部 使 用 行 预 取 。 结 果 ， 当 聚合 是 执 
行 计划 的 一 部 分 时 ,访问 路 径 的 逻辑 读数 会 非常 接近 块 数 。 换 句 话 说 ， 无 论 行 预 取 设置 成 什么 ,每 次 
SQL 引 警 访问 一 个 块 ， 它 都 会 包含 所 有 行 。 下 面 举 例 说 明 : 


SOL> set arraysize 2 


SOL> SELECT sum(n1) FROM 七 ; 


0 | SELECT STATEMENT | :| 
| 1 | SORT AGGREGATE | | ;| 388 | 
2 | TABLE ACCESS FULL| T | 10000 | 


13.1.3 ”原因 


造成 低 效 访问 路 径 的 主要 原因 有 以 下 几 个 。 

口 没有 使 用 适合 的 访问 结构 ( 比如 索引 )。 

口 使 用 了 适合 的 访问 结构 ， 但 是 SQL 语句 的 语法 不 允许 查询 优化 器 使 用 它 。 

口 表 或 索引 是 分 区 的 ， 但 是 无 法 修剪 。 结 果 ， 所 有 的 分 区 都 需要 访问 。 

口 表 和 /或 索引 没有 适当 的 分 区 。 

除了 之 前 列表 中 的 例子 之 外 ， 还 有 另外 两 种 情况 会 导致 低 效 访问 路 径 。 

口 查询 优化 器 做 出 错误 判断 时 ， 可 能 是 由 于 缺少 对 象 统计 信息 ,或 是 由 于 对 象 统计 信息 过 旧 ， 
或 由 于 使 用 了 错误 的 查询 优化 器 配置 。 这 些 没 有 放 在 上 面 的 列表 中 ， 是 因为 默认 对 象 统计 信 
息 必 须 是 最 近 的 并 且 查 询 优化 器 也 是 配置 正确 的 ( 第 8 章 和 第 9 章 详 细 介 绍 了 这 两 个 话题 )。 

口 当 查询 优化 器 自身 出 现 问题 时 ， 比 如 ， 当 出 现 内 部 bug 或 底层 限制 时 。 我 也 不 会 处 理 这 些 ， 因 
为 bug 或 查询 优化 器 限制 涉及 的 问题 太 少 了 。 
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13.1.4 解决 方案 


正如 上 一 部 分 描述 的 那样 ， 要 高 效 执行 SQL 语句 ， 目 标 就 是 最 小 化 逻辑 读 ， 或 者 换 句 话说 ， 使 用 
访问 路 径 访问 更 少 的 块 。 要 达到 这 个 目标 ， 或 许 需 要 增加 新 的 访问 结构 ( 比如 ,索引 ) 或 者 改变 物理 
设计 ( 比如 ， 对 表 或 者 它们 的 索引 进行 分 区 )。 给 定 的 SQL 语句 ， 会 有 很 多 访问 结构 和 物理 设计 的 组 
合 。 幸 运 的 是 ， 为 了 使 选择 更 容易 ， 可 以 根据 选择 性 将 SQL 语句 (或 者 更 容易 些 ， 数 据 访问 操作 ) 分 
成 以 下 两 大 类 别 : 

口 弱 选 择 性 操作 

口 强 选 择 性 操作 

选择 性 很 重要 ， 因 为 访问 结构 和 设计 对 弱 选 择 性 操作 支持 较 好 ， 对 强 选 择 性 操作 支持 较 差 .反之 
亦 然 。 然 而 ， 请 注意 这 两 个 类 别 并 没有 明确 的 界限 。 相 反 ， 它 是 依赖 于 操作 的 ， 依 赖 于 它 处 理 的 数据 
和 数据 存储 的 方式 。 例 如 ， 数 据 分 布 和 每 块 存储 行 数 严重 影响 着 性 能 。 换 句 话 说， 并 没有 这 样 绝对 的 
说 法 : 选择 率 小 于 0.1 必 定 是 强 选 择 性 ， 而 超过 这 个 值 就 是 弱 选 择 性 ( 或 其 他 任何 你 想到 的 值 )， 尽 管 
如 此 ， 实 际 上 限制 的 范围 通常 是 0.05~0.25。 如 图 13-1 所 示 ， 你 只 能 确认 接近 0 或 1 的 值 。 


< J 
一 


0 1 
图 13-1 在 强 、 弱 选择 性 之 间 并 没有 固定 的 界限 


重点 需要 明白 要 决定 一 个 操作 的 类 别 ， 与 它 返 回 的 行 数 完全 无 关 ， 只 与 选择 性 有 关 。 例 如 ， 一 个 
操作 返回 500 000 行 与 选择 的 访问 路 径 完全 无 关 。 相 反 ， 一 个 操作 的 选择 性 为 0.001， 可 以 明确 地 把 它 
放 在 强 选 择 性 类 别 中 。 

类 别 对 于 选择 访问 路 径 的 类 型 很 重要 ， 它 关联 着 高 效 的 执行 计划 。 图 13-2 概 括 地 将 选择 性 与 访 
问 路 径 关 联 在 一 起 ， 通 常 来 说 这 是 最 优化 的 方式 。 当 使 用 合适 的 索引 时 ， 可 以 高 效 地 执行 强 选 择 性 
操作 ,在 本 章 稍 后 的 部 分 , 可 以 看 到 在 一 些 场景 中 rowid 访 问 或 散 列 群集 也 可 能 会 有 帮助 。 另 一 方面 ， 
通过 读 取 全 表 ， 可 以 高 效 执行 弱 选择 性 操作 。 在 这 两 种 可 能 性 之 间 ， 分 区 表 和 散 列 群集 扮演 着 重要 
的 角色 。 


2 


0 1 
图 13-2 ”指定 的 访问 路 径 只 有 在 指定 的 选择 性 范围 内 才能 高 效 执行 


注意 将 数据 存储 在 Exadata 存 储 服务 器 上 时 ， 使 用 smart scan 操 作 可 以 利用 存储 索引 (storage index ) 
来 减少 从 磁盘 物理 读 取 的 数据 量 。 因 此 ， 一 些 平衡 选择 性 的 操作 或 者 强 选择 性 的 操作 ， 可 以 
高 效 执行 读 取 全 表 。 我 们 不 能 控制 存储 索引 ， 它 们 由 Exadata 存 储 服 务 器 自动 管理 。 因 此 ， 本 
章 不 会 介绍 关于 存储 索引 的 内 容 . 


让 我 们 来 看 两 个 演示 实验 。 在 第 一 个 实验 中 ， 取 回 单 行 数据 ， 而 第 二 个 实验 取 回 了 上 千 行 数据 。 
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1. 取 回 单行 
这 个 实验 使 用 access_structures 1.sql 脚 本 ,目的 是 用 取 回 一 行 数据 所 需要 的 逻辑 读数 与 以 下 适 
当 的 访问 结构 进行 对 比 : 
口 带 有 主键 ( primary key ) 的 堆 表 ( heap table ) 
口 索引 组 织 表 ( index_organized table ) 
口 主键 作为 群集 键 ( cluster key ) 的 单 表 散 列 群 集 ( single-table hash cluster ) 


注意 ”本 章 只 介绍 处 理 SQL 语 句 期 间 如 何 利 用 不 同类 型 的 段 ( 比如 表 、 和 群集 和 索引 ) 最 小 化 逻辑 读 
可 以 在 Oracle Database Concepts 手 册 中 找到 它们 的 基本 信息 ， 尤 其 是 “Schema Objects” 这 一 章 


下 面 是 用 于 实验 的 查询 。 请 注意 ，id 列 是 这 个 表 的 主键 。 存 在 值 为 6 的 行 ， 并 是 rid 变 量 保存 着 对 
应 行 的 rowid: 


SELECT * FROM sales WHERE id = 6 


SELECT * FROM sales WHERE rowid = :rid 
由 于 逻辑 读数 与 索引 高 度 相关 ， 实 验 在 保存 了 10、10 000 和 1 000 000 行 的 表 上 执行 。 图 13-3 汇 总 
了 结 上 它们 阐述 以 下 四 种 主要 事实 . 

口 对 于 所 有 的 访问 结构 ， 都 是 通过 rowid ( 显然 ， 要 读 取 这 行 保存 的 块 ， 你 无 法 做 到 比 这 个 还 少 
的 逻辑 读 ) 执行 单个 多 辑 读 的 。 

口 对 于 堆 表 来 说 ， 至 少 需要 两 个 逻辑 读 : 一 个 用 于 索引 ， 男 一 个 用 于 表 。 随 着 行 数 的 增加 ， 索 
引 高 度 的 增加 ， 逮 辑 读数 也 会 增加 。 

口 访问 索引 组 织 表 可 以 比 访问 堆 表 少 一 个 逻辑 读 。 

口 对 于 单 表 散 列 和 群集， 不 仅 逻 辑 读数 不 依赖 于 行 数 ， 而 且 它 总 是 导致 单个 逻辑 读 。 


4 
3 
未 口 10 行 
英 鳃 10 000 行 
| 一 
图 1 000 000 行 
1 
0 
Rowid i 索引 组 织 表 单 表 散 列 聚 签 


图 13-3 不 同 的 访问 结构 导致 不 同 的 逻辑 读数 
要 取 回 单行 ,一 个 “普通 ”的 表 加 上 索引 是 最 低 效 的 访问 结构 。 然 而 ， 正 如 我 在 本 章 后 续 
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描述 的 那样 ， 最 常用 的 是 “普通 ”的 表 ， 因 为 只 有 在 特殊 场景 才 可 以 利用 其 他 访问 结构 。 


2. 取 回 多 行 
这 个 实验 基于 access_structures_1000.sql 脚 本 , 目的 是 用 取 回 上 千 行 数据 所 需 的 逻辑 读数 , 与 以 
下 适当 的 访问 结构 进行 对 比 。 

口 没有 索引 的 非 分 区 表 。 

口 列表 分 区 表 。Przod category 列 是 分 区 列 。 

口 单 表 散 列 和 群集 。pProd_category 列 是 群集 键 。 

口 在 prod_category 列 上 有 索引 的 非 分 区 表 。 对 于 这 个 实验 ， 会 测试 表 中 的 行 分 布 在 两 个 不 同 的 
段 的 情况 〈( 因 此， 存在 不 同 的 群集 因子 )。 

测试 的 数据 集 包 含 918 843 行 。 下 面 的 查询 显示 prod_category 列 的 数据 分 布 情况 : 

SOL> SELECT prod category, count(*), ratio to report(count(*)) over() AS selectivity 
2 FROM sales 


3 GROUP BY prod category 
4 ORDER BY count(*); 


PROD_CATEGORY COUNT(*) SELECTIVITY 


Hardware 15357 xs 
Photo 95509 .104 
Electronics 116267 4127 
Peripherals 286369 .31 
Software/Other 405341 .441 
以 下 是 用 来 测试 的 查询 : 


SELECT sum(amount sold) FROM sales WHERE prod_category = "Hardware' 
SELECT sum(amount sold) FROM sales WHERE prod category = 'Photo’ 
SELECT sum(amount sold) FROM sales WHERE prod category = 'Electronics' 
SELECT sum(amount sold) FROM sales WHERE prod category = 'Peripherals' 


SELECT sum(amount sold) FROM sales WHERE prod category = 'Software/Other' 


SELECT sum(amount sold) FROM sales 

对 于 每 一 个 查询 ， 都 会 记录 逻辑 读数 。 图 13-4 汇 总 了 结果 ,产生 了 以 下 四 个 要 点 。 

口 没有 索引 的 非 分 区 表 需 要 的 逻辑 读数 与 选择 性 无 关 。 因 此 ， 它 只 在 弱 选 择 性 时 高 效 。 

口 因为 表 已 经 根据 prod_category 列 进行 分 区 ， 所 以 列表 分 区 表 的 单独 一 个 分 区 需要 的 逻辑 读数 
与 选择 性 成 正比 。 因 此 ， 在 所 有 情况 下 ， 会 实施 最 小 逻辑 读 。 

口 单 表 散 列 群集 需要 的 逻辑 读数 仅 跟 选择 性 中 等 和 高 的 值 成 正比 ( 正如 稍 后 会 看 到 的 ， 当 选择 
性 强 时 ， 散 列 群集 会 很 有 用。 然而 ， 在 这 个 实验 中 ， 由 于 数据 分 布 不 均匀 ， 它 们 处 于 劣势 )。 

口 通过 索引 读 表 需 要 的 逻辑 读数 非常 依赖 于 数据 物理 分 布 。 因 此 ， 仅 知道 选择 性 不 足以 发 现 访 
问 路 径 是 否 能 高 效 处 理 数据 。 


13.2 ” 弱 选 择 性 的 SQL 语句 409 


O 表 

日 分 区 表 
卓 散 列 聚 禾 
和 索引 (1) 
量 索引 (2) 
+ 选择 性 


利 圭 辟 


照片 ” 电子 设 外 设 软件 全 部 
图 13-4 ”特定 的 访问 路 径 仅 对 特定 范围 的 选择 性 高 效 执行 


现在 你 "i 道 在 不 同 的 情况 下 高 效 访问 数据 的 主要 可 行 方法 , 接 下 来 该 详细 介绍 用 来 处 理 强 和 弱 选 
择 性 SQL 语 句 的 访问 路 径 了 。 . 


13.2 ” 弱 选 择 性 的 SQL 语句 


要 高 效 处 理 数据 ， 弱 选择 性 的 SQL 语 句 需 要 使 用 全 表 扫 描 或 全 分 区 扫描 。 但 是 在 大 多 数 情 况 下 ， 
仅 全 表 扫 描 可 用 。 这 主要 有 三 个 原因 。 第 一 ,分 区 是 企业 版 的 选项 。 因 此 ， 如 果 使 用 标准 版 你 将 不 能 
使 用 它 , 或 者 你 没有 分 区 选项 的 授权 。 第 二 ， 即 使 可 以 使 用 分 区 选项 ， 实 际 上 并 不 是 所 有 的 表 都 会 分 
区 。 第 三 ， 一 张 表 仅 被 有 限 数量 的 列 分 区 。 结 果 就 是 即使 表 是 分 区 的 ， 并 不 是 所 有 的 SQL 语句 都 会 引 
用 它 来 利用 分 区 技术 ， 除 非 它们 都 引用 分 区 键 (partitioning key )， 这 在 实际 中 通常 不 会 发 生 。 

特殊 情况 下 ， 全 表 扫 描 和 全 分 区 扫描 会 被 全 索引 扫描 蔡 代 。 这 种 情况 下 ， 目 的 不 再 是 利用 索引 来 
搜索 特定 的 值 ， 而 仅 是 因为 它们 要 上 比 表 小 。 
13.2.1 全 表 扫 描 

所 有 的 堆 表 上 都 可 以 执行 全 表 扫 描 。 由 于 这 种 扫描 没有 任何 特殊 要 求 ,， 有 时 它 是 唯一 可 用 的 访问 
路 径 。 下面 的 查询 是 个 例子 。 请 注意 在 执行 计划 中 ，TABLE ACCESS FULL 操 作 相 当 于 全 表 扫 描 。 该 例子 
也 展示 了 如 何 使 用 full hint 来 强制 执行 全 表 扫 描 : 

SELECT /*+ full(t) */ * FROM t WHERE n2 = 19 


| Id | Operation | Name | 


| 0 | SELECT STATEMENT | | 
|* 1 | TABLE ACCESS FULL|T | 


1 - filter("N2"=19) 
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在 全 表 扫 描 时 ,服务器 进程 连续 读 取 表 高 水 位 线 下 所 有 的 块 。 直 到 10.2 版 本 ( 包括 该 版 本 ) 服务 
器 进程 才 开 始 执行 缓冲 区 缓存 读 取 。 从 11.1 版 本 之 后 ， 该 类 磁盘 IO 操作 依赖 于 需要 读 取 的 块 数 ， 目 标 
表 的 小 部 分 块 已 在 缓冲 区 缓存 中 ， 无 论 是 否 将 BUFFER_P00L 存 储 参 数 设置 为 KEEP。 简 单 地 说 ， 当 从 磁 
盘 读 取 的 块 数 较 低 或 使 用 了 KEEP 缓 冲 池 时 ， 服 务 器 进程 就 执行 缓冲 区 缓存 读 取 。 此 外 ， 它 们 执行 直接 
读 。 这 个 选项 执行 直接 读 主 要 是 确保 大 量 数据 不 必 通 过 缓冲 区 缓存 加 载 ( 在 这 里 会 被 立即 丢弃 )- 

全 表 扫 描 执行 的 最 小 逻辑 读数 依赖 于 块 数 ， 而 不 是 行 数 。 如 果 表 中 包含 大 量 空 或 者 接近 空 的 块 ， 
就 会 导致 次 优 的 性 能 。 显 然 ， 需 要 读 取 块 才能 知道 它 是 否 包含 数据 。 一 个 导致 表 产 生 大 量 分 布 稀 玻 块 
最 常见 的 场景 就 是 当 表 删除 多 于 插入 时 。 下 面 的 例子 ， 引 用 自 full_scan_hwm.sql 脚 本 生成 的 输出 。 

口 最 初 ， 查 询 执 行 了 468 次 逻辑 读 ， 返 回 40 行 : 

SQOL> SELECT * FROM t WHERE n2 = 19; 
SQL> SELECT last output rows, last cr buffer gets, last cu buffer gets 
2 FROM v$session s, v$sql plan statistics p 
WHERE s.prev sql id = p.sql id 
AND s.prev child number = p.child number 


3 
4 
5 AND s.sid = sys context('userenv','sid') 
6 AND p.operation id = 1; 


LAST_OUTPUT_ROWS LAST CR BUFFER GETS LAST CU BUFFER GETS 


口 接着 ,删除 几乎 所 有 的 行 ( 10 000 行 中 的 9960 行 )。 然 而 ， 执 行 查询 的 逻辑 读数 并 没有 改变 
换 名 话说， 许多 空 块 被 无 用 地 访问 了 : 


SOL> DELETE t WHERE n2 <> 19; 
9960 rows deleted. 
SQOL> SELECT * FROM t WHERE n2 = 19; 


SQL> SELECT last output rows, last cr buffer gets, last cu buffer gets 
2 FROM v$session s, v$sql plan statistics p 
3 WHERE s.prev sql id = p.sql id 
4 AND s.prev child number = p.child number 
5 AND s.sid = sys_context('userenv','sid') 
6 AND p.operation id = 1; 


LAST_OUTPUT_ROWS LAST_CR BUFFER GETS LAST CU BUFFER_GETS 


口 要 降低 高 水 位 线 ， 需 要 物理 重组 表 。 如 果 表 存储 在 自动 段 空间 管理 的 表 空 间 中 , 那么 可 以 使 
用 下 面 的 SQL 语句 。 请 注意 ， 必 须 启 用 行 迁 移 ， 因 为 在 重组 期 间 ， 行 或 许 会 获得 一 个 新 的 
rowid: 


SQOL> ALTER TABLE t ENABLE ROW MOVEMENT; 


SQOL> ALTER TABLE t SHRINK SPACE; 
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口 重组 后 ， 查 询 仅 执行 了 23 逻 辑 读 ， 返 回 40 行 ; 
SOL> SELECT * FROM t WHERE n2 = 19; 


SOL> SELECT last output rows, last cr buffer gets, last cu buffer gets 
2 FROM v$session s, v$sql plan statistics p 
3 WHERE s.prev sql id = p.sql id 
4 AND s.prev child number = p.child number 
5 AND s.sid = sys context('userenv','sid') 
6 AND p.operation id = 1; 


LAST_OUTPUT_ ROWS LAST CR BUFFER GETS LAST CU BUFFER_GETS 


请 注意 , 全 表 扫 描 执行 的 逻辑 读数 强烈 依赖 于 行 预 取 的 设置 。 关于 这 方面 的 例子 , 请 参考 13.1.2 节 。 


13.2.2 ”全 分 区 扫描 


当选 择 性 非常 弱 时 ( 即 ， 接 近 1 )， 全 表 扫 描 是 获取 数据 最 有 效 的 方法 。 随 着 选择 性 的 降低 ， 全 表 
扫描 会 访问 许多 不 需要 的 块 。 由 于 使 用 索引 并 不 益 于 弱 选 择 性 ， 因 此 分 区 是 用 来 减少 逻辑 读数 最 常用 
的 选项 。 使 用 分 区 的 原因 是 利用 查询 优化 器 的 能 力 去 对 分 区 处 理 中 包含 的 不 相关 处 理 数 据 做 排除 。 这 
个 特性 称 作 分 区 裁剪 (partition pruning )。 

要 对 一 个 SQL 语句 使 用 分 区 裁 前 有 两 个 基本 的 先决 条 件 。 第 一 ， 表 必须 是 分 区 的 。 第 二 ， 必 须 在 
SQL 语句 中 指定 对 分 区 键 的 限制 或 联接 条 件 。 如 果 这 两 个 条 件 可 以 满足 ,那么 查询 优化 器 会 用 一 个 或 
多 个 全 分 区 扫描 替换 全 表 扫 描 。 但 在 实践 中 ,事情 没 那 么 简单 。 实 际 上 ， 查 询 优 化 器 需要 处 理 多 个 特 
殊 场 景 或 许 也 可 能 不 会 导致 分 区 裁剪 。 要 更 好 地 理解 这 些 场景 , 接 下 来 的 部 分 会 详 述 分 区 裁剪 的 基础 ， 
也 包含 高 级 裁剪 技术 比如 OR( where 条 件 里 使 用 or )、multicolumn( 多 列 )、subquery( 子 查询 ) 和 join-filter 
pruning ( 联接 过 滤 裁 剪 )。 之 后 是 一 些 关 于 如 何 实施 分 区 的 实用 性 建议 。 请 注意 索引 分 区 会 在 本 章 稍 
后 的 13.3 节 介绍 。 


13.2.3 ”范围 分 区 


要 举例 说 明 分 区 裁剪 的 工作 原理 ， 让 我 们 来 检查 基于 pruning_range.sql 脚 本 的 多 个 例子 。Test 表 
就 是 范围 分 区 并 且 使 用 以 下 SQL 语 名 创建 。 为 了 能 够 展示 所 有 类 型 的 分 区 裁剪 ， 分 区 键 由 两 列 组 成 : 
ni 和 d1。 表 由 n1 列 四 个 不 同 的 值 和 基于 di 列 的 月 份 进 行 分 区 。 这 代表 每 年 有 48 个 分 区 : 


CREATE TABLE t ( 
id NUMBER, 
d1 DATE, 
n1 NUMBER, 
n2 NUMBER, 
n3 NUMBER, 
pad VARCHAR2(4000), 
CONSTRAINT t pk PRIMARY KEY (id) 


) 
PARTITION BY RANGE (n1, d1) ( 
PARTITION t 1 jan 2014 VALUES LESS THAN (1, to date('2014-02-01','yyyy-mm-dd')), 
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PARTITION t 1 feb 2014 VALUES LESS THAN (1, to date('2014-03-01','yyyy-mm-dd')), 
PARTITION t 1 mar 2014 VALUES LESS THAN (1, to date('2014-04-01','yyyy-mm-dd")), 


PARTITION t 4 oct 2014 VALUES LESS THAN (4, to date('2014-11-01','yyyy-mm-dd')), 


PARTITION t 4 nov 2014 VALUES LESS THAN (4, to date('2014-12-01','yyyy-mm-dd' )), 
PARTITION t 4 dec 2014 VALUES LESS THAN (4, to date('2015-01-01','yyyy-mm-dd')) 


警告 像 这 样 存在 两 个 分 区 键 的 案例 ， 如 果 第 一 个 键 无 法 唯一 定位 一 个 单独 分 区 ， 数 据 引 擎 会 仅 使 
用 第 二 个 键 来 插入 新 行 。 因 此 ， 当 指定 PARTITION BY RANGE 子 名 时 ，n1 列 会 指定 在 d1 列 前 


图 13-5 是 Test 表 的 图 示 。 


n1 


BESaaS eae 


Jan Feb Mar Apr May Jun Jul a Sep Oct Nov Dec 
图 13-5 ”Test 表 每 年 由 48 个 分 区 组 成 ' 


每 个 分 区 都 可 以 通过 其 名 称 或 在 表 中 的 “位 置 ”( 后 者 在 图 13-5 中 ) 进行 识别 。 当 然 ， 两 个 值 之 间 
的 映射 可 以 在 数据 字典 中 找到 。 下 面 的 查询 展示 了 如 何 从 user tab_partitions 视 图 中 获取 这 些 信息 
SQL> SELECT partition name, partition position 
2 FROM user tab partitions 


3 WHERE table name = 'T' 
4 ORDER BY partition position; 


PARTITION NAME PARTITION POSITION 


T_1 JAN 2014 

T_1 FEB 2014 2 
T_1 MAR 2014 3 
下 a OCT_2014 46 
T_4 NOV 2014 47 
T_4 DEC 2014 48 


TD 自 12.1.0.2 起 ，PARTITON RANGE ITERATOR 操 作 也 用 于 基于 区 域 图 的 分 区 裁剪 
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对 于 这 个 表 来 说 ， 如 果 在 分 区 键 上 有 限制 ,查询 优化 器 就 能 识别 出 并 且 能 够 排除 包含 处 理 不 相关 

pe 由 于 数据 字典 中 包含 分 区 的 界限 ， 因 此 查询 优化 天 可 以 使 它们 与 SQL 语句 中 的 限制 或 联 

接 条 件 作对 比 。 然 而 ， 由 于 限制 ， 分 区 裁剪 并 不 总 是 可 用 。 下 一 人 小节 会 展示 不 同 的 例子 来 指出 查询 优 
化 器 在 何 时 、 如 何 使 用 分 区 裁剪。 


注意 ”这 部 分 例子 中 只 使 用 了 查询 。 这 并 不 代表 分 区 栽 葛 只 能 应 用 于 查询 。 实 际 上 ， 它 也 可 以 应 用 
于 同样 的 SQL 语句 ， 如 UPDATE 和 DELETE。 只 是 为 了 方便 起 见 我 才 只 使 用 查询 


1. PARTITON RANGE SINGLE 

下 面 的 SQL 语 句 ，WHERE 子 句 包含 两 个 限制 : 对 应 分 区 键 的 每 列 。 在 这 样 的 情况 下 , 查询 优化 器 识 
别 出 只 有 单独 一 个 分 区 包含 相关 数据 。 结 果 ， 在 执行 计划 里 会 显示 PARTITION RANGE SINGLE 操 作 。 重 
点 需要 知道 它 的 子 操作 ( TABLE ACCESS FULL ) 并 不 是 对 整 张 表 进行 全 表 扫 描 。 相 反 ， 只 访问 了 单独 一 
个 分 区 。 这 也 被 starts 列 的 值 所 证 实 。Pstart 和 Pstop 列 指明 了 访问 的 分 区 : 

SELECT * FROM t WHERE n1 = 3 AND di = to date('2014-07-19"','yyyy-mm-dd') 


0 | SELECT STATEMENT | 1 | 
| 1| PARTITION RANGE SINGLE| | 4| 至上 | 31| 
-| TABLE ACCESS FULL |T | 1 | 


2 - filter("D1"=TO DATE(' 2014-07-19 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "N1"=3) 
图 13-6 为 这 种 行为 的 示意 图 。 


ni 


图 13-6 ”PARTITION RANGE SINGLE 操 作 的 表现 


正如 下 面 查询 的 输出 显示 ,Pstart 和 Pstop 列 的 分 区 数 与 user tab_partitions 视 图 中 的 partition 
position 列 的 值 吻合 : 
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SQL> SELECT partition name 
2 FROM user tab partitions 
3 WHERE table name = 'T' 
4 AND partition position = 31; 


PARTITION NAME 


T_3_JUL 2014 

每 当 绑 定 变 量 在 限制 中 使 用 时 , 查询 优化 器 就 不 能 在 解析 阶段 判断 该 访问 哪个 分 区 。 这 种 情况 下 ， 
分 区 裁剪 在 运行 时 执行 。 执 行 计划 不 会 改变 ,但 是 Pstart 和 Pstop 列 会 设置 成 KEY。 这 代表 发 生 了 分 区 
裁剪 ， 但 是 在 解析 阶段 ， 查 询 优化 器 并 不 知道 哪个 分 区 包含 了 相关 数据 : 


SELECT * FROM t WHERE n1 = :n1 AND d1 = to date(:d1,'YYYY-MM-DD') 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 1 | | | 
| 1 | PARTITION RANGE SINGLE| | :| KEY | KEY | 
l* 2| TABLE ACCESS FULL |T | 1| KEY | KEY | 


2 - filter(("D1"=TO DATE(:D1, 'YYYY-MM-DD') AND "N1"=:N1)) 


2. PARTITION RANGE ITERATOR 

上 一 部 分 介绍 的 执行 计划 包含 PARTITION RANGE SINGEL 操 作 。 这 是 因为 查询 优化 器 识别 出 用 户 只 
有 单独 一 个 分 区 包含 相关 处 理 数 据 。 显 然 , 会 存在 需要 访问 多 个 分 区 的 情况 。 例 如 , 在 下 面 的 查询 中 ， 
限制 使 用 了 小 于 条 件 (< ) 而 不 是 相等 条 件 (= )， 因 此 ， 操 作 变 成 了 PARTITION RANGE ITERATOR， 并 且 
Pstart 和 Pstop 列 显示 被 访问 的 分 区 范围 ( 请 查看 图 13-7 )。 此 外 ，Starts 列 显示 操作 1 只 执行 了 一 次 ， 
但 是 操作 2 每 个 分 区 执行 了 一 次 。 换 句 话 说， 执行 了 多 次 全 分 区 扫描 : 


SELECT *# FROM 七 WHERE n1 = 3 AND d1 «< to date('2014-07-19','YYYY-MM-DD') 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | dr | | 
| 1 | PARTITION RANGE ITERATOR| | gd | | 
|* 2 | TABLE ACCESS FULL Wi 到 7 | | 31| 


2 - filter(("N1"=3 AND "D1"<TO DATE(' 2014-07-19 00:00:00'", 'syyyy-mm-dd hh24:mi:ss'))) 


13.2” 弱 选择 性 的 SQL 语句 


ni 


EPEEEEDDDDDDO 
回回 回回 回回 回回 回回 目 百 
四 加 四 四 加 加 加 加 | 加 加 


Oct Nov Dec 


di 


Aug Sep 


图 13-7 PARTITION RANGE ITERATOR 操 作 表 现 ? 


PARTITION RANGE ITERATOR 操 作 也 会 用 于 当 限 制 基于 分 区 键 的 前 导 列 时 。 下 面 的 查询 举例 说 明 ， 限 
制 应 用 于 分 区 键 的 第 一 个 列 上 。 请 注意 也 会 访问 分 区 37。 这 是 因为 如 果 d1 列 存在 大 于 2014 年 12 月 31 日 


的 值 ， 那 么 n1 列 等 于 3 的 行 就 存储 在 这 个 分 区 里 : 
SELECT * FROM t WHERE nl = 3 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 1 | | | 
| 1 | PARTITION RANGE ITERATOR| | 1| 25| 37| 
|* 2 | TABLE ACCESS FULL jw | 13 | | 3 驴 | 


2 - filter("N1"=3) 


就 像 这 个 操作 的 名 称 所 暗示 的 那样 ， 它 只 对 连续 的 分 区 范围 有 效 。 当 使 用 非 连续 分 区 时 ， 就 会 用 


到 下 一 节 的 操作 。 


3. PARTITION RANGE INLIST 


如 果 限 制 基于 一 个 或 多 个 由 超过 一 个 元 素 组 成 的 IN 条 件 时 ， 那 么 在 执行 计划 中 就 会 有 PARTITION 
RANGE INLIST 操 作 。 使 用 这 个 操作 ，Pstart 和 Pstop 列 不 会 给 出 访问 哪个 分 区 的 具体 信息 。 相 反 ， 它 们 
会 显示 KEY(I) 的 值 。 这 代表 对 IN 条 件 中 的 每 个 值 分 别 执行 分 区 裁 前 。 此 外 ，Starts 列 显示 访问 了 多 少 


个 分 区 (本 例 为 2 ): 
SELECT * FROM t WHERE n1 IN (1,3) AND d1 = to date('2014-07-19','YYYY-MM-DD') 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 1 | | | 
| 1 | PARTITION RANGE INLIST| | 1 |KEY(I) |KEY(I) | 


CD 自 12.1.0.2 起 ，PARTITION RANGE ITERATOR 操 作 也 用 于 基于 区 域 图 的 分 区 裁剪 。 
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|* 2| TABLE ACCESS FULL |T | 2 |KEY(I) |KEY(I) 


2 - filter(("D1"=TO DATE(' 2014-07-19 00:00:00', 'syyyy-mm-=dd hh24:mi:ss') AND 
INTERNAL FUNCTION("N1"))) 


在 此 特定 案例 中 ， 根 据 NHERE 子 句 ， 可 以 推断 出 仅 会 访问 分 区 7 和 31。 图 13-8 说 明了 这 一 点 。 


ni 


加 本 六 六 甩 
: Aug Sep Oct Nov Dec 
图 13-8 ”PARTITION RANGE INLIST 操 作 表 现 
当然 ， 如 果 IN 条 件 中 的 值 是 完全 分 散 的 ， 那 就 有 可 能 大 部 分 分 区 都 要 访问 到 。 这 种 情况 下 执行 计 
划 会 认为 所 有 分 区 都 需要 访问 ， 就 会 使 用 下 一 节 的 操作 。 


4. PARTITION RANGE ALL 
如 果 在 分 区 键 上 没有 限制 , 那么 所 有 分 区 都 必须 访问 。 这 种 情况 下 , 执行 计划 包含 PARTITION RANGE 
ALL 操 作 ， 并 且 Starts 、Pstart 和 Pstop 列 显示 所 有 分 区 都 会 被 访问 : 


SELECT * FROM t WHERE n3 BETWEEN 6000 AND 7000 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 1 | | | 
| 1 | PARTITION RANGE ALL| | T | 1 | 48 | 
|* 2| TABLE ACCESS FULL |T | 48 | | 本 | 


2 - filter(("N3">=6000 AND "N3"<=7000)) 

在 主键 上 使 用 不 等 式 作为 限制 时 ， 也 会 使 用 这 个 相同 的 执行 计划 。 下 面 的 查询 是 一 个 例子 : 

SELECT * FROM 七 WHERE n1 != 3 AND d1 != to date('2014-07-19' ，YYYY-MM-DD ) 

当 在 分 区 键 上 基于 表达 式 或 函数 进行 限制 时 ， 也 会 使 用 相同 的 执行 计划 。 例 如 ， 下 面 的 查询 ， 在 
ni 列 上 加 1， 并 且 通 过 to_char 函 数 修改 d1 列 : 

SELECT * FROM t WHERE n1 + 1 = 4 AND to _ char(d1，YYYY-MM-DD') = '2014-07-19" 

这 代表 要 利用 分 区 裁剪 ， 不 仅 要 基于 分 区 键 的 限制 ， 而 且 不 能 在 分 区 键 上 使 用 表达 式 或 函数 。 如 
果 必 须要 使 用 表达 式 ， 从 11.1 版 本 开始 ， 可 以 选择 虚拟 列 作为 主键 。 
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5. PARTITION RANGE EMPTY 

当 查 询 优化 器 发 现 没 有 分 区 保存 相关 人 处理 数据 时 ， 执 行 计划 中 会 出 现 这 个 特别 的 操作 PARTITION 
RANGE EMPTY。 例 如 ， 下 面 的 查询 查找 的 数据 没有 分 区 保存 ( 对 于 ni 列 来 说 ,， 值 5 超出 了 范围 )。 同 样 需 
要 注意 的 是 ， 不 仅 会 将 Pstart 和 Pstop 列 设置 为 INVALID， 而 且 只 会 执行 操作 1 (不 会 消耗 任何 资源 ， 因 
为 基本 上 这 是 个 空 操作 ): 

SELECT * FROM t WHERE n1 = 5 AND d1 = to date('2014-07-19"','YYYY-MM-DD' ) 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 
| 1 | PARTITION RANGE EMPTY | 1 |INVALID|INVALID| 
|* 2 | TABLE ACCESS FULL |T 0 |INVALID|INVALID| 
2 - filter(("D1"=TO DATE(' 2014-07-19 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "N1"=5)) 


6. PARTITION RANGE OR 

本 节 介 绍 的 裁剪 类 型 ， 也 叫 作 OR 裁 剪 ， 它 是 分 区 键 上 的 分 隔 谓词 用 在 了 WHERE 子 句 上 (由 OR 条 件 
组 合 的 谓词 )。 下 面 的 查询 就 是 这 样 的 例子 。 当 使 用 这 种 类 型 的 裁 前 时， 执行 计划 中 出 现 PARTITION 
RANGE OR 操作 。 请 注意 Pstart 和 Pstop 列 也 会 被 设置 为 KEY(OR)。 在 下 面 的 例子 中 ， 根 据 starts 列 ， 会 访 
问 18 个 分 区 。 之 所 以 是 18 个 分 区 ， 是 因为 尽管 应 用 在 n1 列 上 的 限制 访问 分 区 25 和 37，, 但 是 应 用 在 d1 列 
上 的 限制 访问 分 区 1、3、13、15、25、27、37 和 39 ( 分 区 1 用 来 找 出 是 否 存在 包含 n1 列 值 在 PARTITION BY 
RANGE 子 句 中 未 指定 上 限 的 行 ): 

SELECT * FROM t WHERE n1 = 3 OR d1 = to _date('2014-03-06','YYYY-MM-DD' ) 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 1 | | 

| 1 | PARTITION RANGE OR| | 1 |KEY(OR)|KEY(OR)| 
l* 2| TABLE ACCESS FULLI T | 18 |KEY(OR)|KEY(OR) | 


2 - filter(("N1"=3 OR "D1"=TO DATE(' 2014-03-06 00:00:00', 'syyyy-mm-dd hh24:mi:ss ))) 
7. PARTITION RANGE SUBQUERY 
在 之 前 的 部 分 中 ， 所 有 用 来 分 区 裁剪 的 限制 都 是 基于 文字 或 绑 定 变量 。 然 而 ， 限 制 是 联接 条 件 的 
情况 也 很 常见 。 每 当 基于 分 区 键 联接 时 ， 不 仅 查询 优化 器 不 会 总 利用 分 区 裁剪 ， 而 且 在 一 些 情况 下 这 
么 做 也 是 不 明智 的 。 要 选择 最 低 成 本 的 执行 计划 ， 碍 询 优 化 器 需要 在 三 种 策略 中 选择 。 


注意 第 14 章 会 详细 介绍 联接 方法 。 


绢 


第 一 种 策略 是 避免 使 用 分 区 裁剪 。 下 面 的 查询 ( 请 注意 tx 表 是 t 表 的 副本 ; 唯一 的 不 同 是 tx 表 没 
有 分 区 ) 举例 说 明 ，t 表 上 没有 执行 分 区 裁剪 。 实 际 上 ， 因 为 操作 4 是 PARTITON RANGE ALL， 操 作 5 处 理 


418 第 13 章 优化 数据 访问 


了 所 有 分 区 。 在 本 例 中 ， 执 行 计划 是 非常 低 效 的 。 尤 其 是 当 查 询 的 选择 性 强 时 : 
SELECT * FROM tx, t WHERE tx.d1 = t.dl AND tx.n1 = t.n1 AND tx.id = 19 


| Id | 0peration | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 1 | | 
|* 1 | HASH JOIN | | 4 | | 

| 2| TABLE ACCESS BY INDEX ROWID| TX | :| | 
|* 3 | INDEX UNIOUE SCAN | TX_PK | 1 | | 
| 4 | PARTITION RANGE ALL | | 1 | 4 48 | 
| 5| TABLE ACCESS FULE | T | 48 | 1 48 | 


1 - access("TX"."D1"="T"."D1" AND "TX"."N1"="T"."N1") 
3 - access("TX"."ID"=19) 
这 种 策略 总 是 有 效 的 。 然 而 ， 如 果 联 接 条 件 的 选择 性 不 接近 于 1， 或 者 换 句 话说 ， 在 应 用 分 区 裁 
剪 的 情景 中 ， 就 会 导致 糟糕 的 性 能 ，。 
第 二 种 策略 是 使 用 NESTED LOOPS 操 作 来 执行 联接 并 访问 表 ， 这 会 触发 作为 第 二 个 子 操作 的 分 区 裁 
剪 。 实 际 上 ， 正 如 在 第 10 章 中 讨论 的 那样 ，NESTED LOOPS 操 作 是 关联 合并 操作 ， 因 此 ， 它 的 第 一 个 子 
操作 控制 着 第 二 个 子 操作 。 下 面 的 例子 展示 了 这 样 的 场景 。 请 注意 PARTITION RANGE ITERATOR 操 作 以 
及 Pstart 和 Pstop 列 的 值 证实 发 生 了 分 区 裁剪 。 根 据 Starts 列 ， 会 访问 单独 一 个 分 区 。 在 本 例 中 ， 下 面 
的 执行 计划 要 远 比 第 一 种 策略 使 用 的 执行 计划 高 效 : 
SELECT * FROM tx, t WHERE tx.d1 = 七 .d1 AND tx .nl = tinl AND fx id = 349 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 1 | | | 
| 1 |_ NESTED LOOPS | | 1 | | | 
| 2| TABLE ACCESS BY INDEX ROWID| TX | 1 | | | 
|* 3 | INDEX UNIQUE SCAN | Tx_Pk | 1 | | | 
| 4 | PARTITION RANGE ITERATOR | | 1| KEY | KEY | 
|* 5| TABLE ACCESS FULL [TT | 1| KEY | KEY | 


3 - access("TX"."ID"=19) 
5 - filter(("TX"."Di"="T"."Di" AND "TX"."Ni"="T",."Ni")) 


这 种 策略 只 有 在 NESTED LOOP 操 作 (本 例 为 操作 2 ) 的 第 一 个 子 操作 返回 的 行 数 很 小 时 才能 表现 良 
好 。 和 否则 ， 很 可 能 同样 的 分 区 会 被 第 二 个 子 操作 (本 例 为 操作 4 ) 访问 很 多 次 。 

第 三 种 策略 是 使 用 HASH JOIN 或 MERGE JOIN 操作 来 执行 联接 。 没 有 基于 常规 分 区 使 用 这 些 联接 方法 
的 联接 条 件 进行 裁剪 。 实 际 上 ， 正 如 第 10 章 介绍 的 那样 ， 它 们 是 非 关 联合 并 操作 ， 因 此 ， 两 个 子 操作 
会 单独 执行 。 这 种 情况 下 , 查询 优化 器 会 利用 另 一 种 类 型 的 分 区 裁 前 , 子 查询 裁剪 ( subquery pruning )。 
它 的 目的 是 通过 递归 查询 找 出 第 二 个 子 操作 应 该 访问 哪个 分 区 。 为 了 这 个 目的 ，SQL3 引 擎 执行 递归 查 
询 ( 通过 第 一 个 子 操作 访问 表 ) 来 取 回 联接 条 件 与 第 二 个 子 操作 分 区 键 匹配 的 列 。 接 着 ,查询 存储 在 
数据 字典 中 第 二 个 子 操作 的 分 区 定义 , 识别 出 被 第 二 个 子 操作 访问 的 分 区 ,这样 就 仅 需 扫描 它们 。 下 
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面 的 查询 举例 说 明 。 请 注意 PARTITION RANGE SUBQUERY 操 作 和 Pstart 与 Pstop 列 的 值 (KEY(S0) ) 证 实 发 
生 了 分 区 裁剪 。 根 据 Starts 列 ， 访 问 了 单独 一 个 分 区 : 
SELECT * FROM tx, t WHERE tx.d4 s t.di AND tx.nl = t.ni AND 人 .ad = 19 


| Id Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 1 | | | 
| 玛 HASH JOIN | | 了 | | | 
ff 训 TABLE ACCESS BY INDEX ROWID| TX | 1 | | | 
|* 3| INDEX UNIOUE SCAN | TX PK | 1 | | 

| 4 PARTITION RANGE SUBQUERY | | 1 |KEY(SQ) |KEY(SQ) | 
| 号 TABLE ACCESS FULL | | 1 |KEY(SQ)|KEY(SQ)| 


1 - access("TX"."D1"="T"."D1" AND "TX". "Ni"="T". "Ni") 
3 - access("TX"."ID"=19) 


事实 上 ，SQL 引 警 递 归 执 行 了 以 下 操作 来 找 出 需要 访问 的 分 区 。 这 个 递归 查询 取 回 包含 
tb1l$or$idx$part$num 函 数 与 相关 数据 的 分 区 数 。 操 作 5 可 以 利用 这 个 信息 使 用 分 区 裁剪 。 例 如 ， 本 例 
中 只 需 扫描 分 区 37: 3 


SQL> SELECT DISTINCT TBL$OR$IDX$PARTSNUM("T", 0, 1, 0, "Ni", "D1") AS PART_NUM 
2 FROM (SELECT "TX"."N1"” "N14", "TX"."D1"” "D1" 


3 FROM "TX"” "TX" 
4 WHERE "TX"."ID"=19) 
5 ORDER BY 1; 
PART_NUM 
37 


很 明显 ， 仅 在 递归 查询 执行 引起 的 开销 小 于 分 区 裁剪 增加 的 开销 时 ， 使 用 第 三 种 技术 才 有 意义 。 
对 于 本 例 中 使 用 的 查询 ， 第 二 种 和 第 三 种 策略 生成 的 执行 计划 效率 是 非常 相似 的 。 然 而 ， 如 果 选 择 性 
弱 ， 第 三 种 策略 生成 的 执行 计划 会 更 有 效率 。 


8. PARTITION RANGE JOIN-FILTER 

子 查询 裁剪 是 非常 有 用 的 优化 技术 。 然而 , 正如 前 面部 分 讨论 的 那样 , 部 分 SQL 语句 会 执行 两 次 。 
为 了 避免 这 种 两 次 执行 的 情况 ， 从 11.1 版 本 开始 ， 数 据 引擎 提供 了 另 一 类 的 分 区 裁剪 : 联接 过 滤 裁 前 
(join-filter pruning， 也 被 称 为 bloom-filter pruning )。 要 理解 它 的 工作 原理 ， 让 我 们 看 一 下 与 子 查询 裁 
剪 部 分 相同 的 查询 生成 的 执行 计划 。 请 注意 会 出 现 一 些 新 东西 : PART JOIN FILTER CREATE 操 作 、 
PARTITION RANGE JOIN-FILTER 操 作 和 在 Name ，Pstart 和 Pstop 列 上 的 字符 串 BF0000。 

SELECT * FROM tx, t WHERE tx.di = t.d1 AND tx.n1i = t.n1 AND tx.id = 19 


| Id | Operation | Name | Starts | E-Rows | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 1 | | | | 
|* 1 | HASH JOIN | | 1 | | | | 
| 2| PART JOIN FILTER CREATE | :BFoooo | 1 | 1 | | | 
| 3| TABLE ACCESS BY INDEX ROWID| TX | 1 | 1 | | | 


420 第 13 章 优化 数据 访问 


这 源 | INDEX UNIQUE SCAN | WP | 1 |: 和 | | 
| 5 | PARTITION RANGE JOIN-FILTER | | 1 | 10000 |:BF0000|:BFo000| 
| 6| TABLE ACCESS FULL Rr | 1 | 10000 |:BF0000|:BF0000| 


1 = access("TX”."Ni"="T", "Ni" AND "TX"."D1"="T","D1i") 
4 - access("TX"."ID"=19) 
执行 计划 的 执行 如 下 所 示 。 
口 操作 3 和 4 通过 tx_pk 索 引 访 问 tx 表 。 
口 根据 操作 3 返回 的 数据 , 操作 2 基于 在 联接 条 件 ( tx.d1 和 tx.n1 ) 中 使 用 的 列 值 创建 内 存 结构 ( 布 
口 根据 操作 2 创建 的 内 存 结构 ， 操 作 5 能 够 利用 分 区 裁剪 ， 因 此 能 够 只 访问 包含 相关 数据 的 分 区 。 
这 种 情况 下 ， 会 访问 单独 分 区 ( 请 查看 Starts 列 )。 


9. PARTITION RANGE MULTI-COLUMN 

如 果 分 区 键 由 多 列 组 合 而 成 ， 重 点 需要 观察 当 限制 没有 固定 在 所 有 列 上 时 会 发 生 什么 。 主 要 问题 
是 ,查询 优化 器 会 利用 分 区 裁剪 吗 ” 答案 是 ， 会 利用 多 列 栽 剪 (multicolumn pruning )。 多 列 裁剪 的 目 
的 很 简单 : 不 依赖 于 限制 定义 的 列 ， 总 会 发 生 分 区 裁剪 。 

让 我 们 看 一 下 这 个 特性 在 之 前 相同 实验 中 的 作用 。 由 于 Test 表 的 分 区 键 是 由 两 列 组 成 的 ， 因 此 需 
要 考虑 两 种 情况 : 限制 会 应 用 在 第 一 列 或 第 二 列 。 下 面 的 查询 举例 说 明 前 者 : 


SELECT * FROM t WHERE n1 = 3 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | | | | 
| 1| PARTITION RANGE ITERATOR| | 1| 25| 37| 
|* 2 | TABLE ACCESS FULL jw | 13 | | 用 :| 


2 - filter("N1"=3) 

下 面 的 查询 举例 说 明 后 者 。 请 注意 PARTITION RANGE MULTI-COLUMN 操 作 以 及 Pstart 和 Pstop 列 的 值 
证 实 发 生 了 分 区 裁剪 ; 然而 ， 并 没有 提供 具体 访问 了 哪个 分 区 : 

SELECT * FROM 七 WHERE d1 = to date('2014-07-19';'YYYY-MM-DD' ) 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 下 

| 1 | PARTITION RANGE MULTI-COLUMN| | 1 |KEY(MC)|KEY(MC) | 
|* 2 | TABLE ACCESS FULL I 8 |KEY(MC)|KEY(MC)| 


2 - filter("D1"=TO DATE(' 2014-07-19 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) 


10. PARTITION RANGE AND 
在 某 些 情况 下 ， 正 如 前 面部 分 介绍 的 那样 ， 查 询 优化 器 可 以 利用 多 个 裁 前 技术。 例如， 请 查看 下 
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面 的 查询 : 
SELECT * FROM tx, t WHERE tx.dl = t.d1 AND tx.n1 = tn1 AND t.n1 = 3 AND tx.n2 = 42 
查询 优化 器 需要 对 这 样 的 SQL 语句 考虑 至 少 使 用 以 下 两 种 裁剪 技术 。 
口 基于 t.n1 = 3 限制 的 分 区 裁剪 : 


| Id | Operation | Name | Starts | Pstart| Pstop | Buffers | 
| 0 | SELECT STATEMENT | | 1 | | | 889 | 
|* 1 | HASH JOIN | | 1 | | | 889 | 
[| TABLE ACCESS FULL | Tx | || | | 403 | 
| 3 | PARTITION RANGE ITERATOR| | 站 要 | 蚤 "| 486 | 
|* | TABLE ACCESS FULL | 本 | 13, | 25, | 37 | 486 


1 - access("TX"."Ni"="T"."N4" AND "TX"."D1"="T"."D1") 
filter(("TX"."N2"=42 AND "TX"."N1"=3)) 
4 - filter("T"."N1"=3) 


口 基于 tx.d1 = t.d1 和 tx.n1 = t.n1 联 接 条 件 (利用 tx.n2 = 42 限 制 ) 的 分 区 裁剪 : 


1 


| Id Operation Name Starts | Pstart| Pstop | Buffers 
| 0 | SELECT STATEMENT 1 963 
|* 1 | HASH JOIN 1 963 
| “这 PART JOIN FILTER CREATE :BF0000 1 403 
| 3 TABLE ACCESS FULL TX 1 403 
| 4 PARTITION RANGE JOIN-FILTER 1 | :BF0000| :BF0000 560 
| 入 5 TABLE ACCESS FULL 15 | :BF0000| :BF0000 560 


1 ~ access ("TX "Nir"T" NL" AND "TX". "DI"="T". "D1") 
3 - filter("TX"."N2"=42) 
5 - filter("T". "Ni"=3) 


从 11.2 版 本 起 ， 查 询 优 化 器 可 以 同时 利用 多 个 裁 前 技术。 这 可 以 保证 访问 最 少 的 分 区 ( 对 比 这 三 
种 情况 的 Starts 列 )。 下面 的 例子 显示 当 使 用 这 种 叫 作 AND 裁 剪 的 类 型 时 执行 计划 中 会 出 现 PARTITION 
RANGE AND 操 作 。 也 请 注意 Pstart 和 Pstop 列 被 设置 为 KEY(AP)。 在 本 例 中 ,分 区 裁剪 基于 限制 (t.n1=3) 
和 联接 条 件 (tx.d1 = t.d1 AND tx.n1 = t.n1 )。 请 注意 为 联接 条 件 创建 的 布 隆 过 滤器 : 


SELECT * FROM tx, t WHERE tx.d1 = 七 .d1 AND tx.n1 = t.n1 AND t.n1 = 3 AND tx.n2 = 42 
Id Operation Name Starts | Pstart| Pstop | Buffers 
0 | SELECT STATEMENT | | 630 | 
HASH JOIN | | 630 
2 PART JOIN FILTER CREATE| :BF0000 1 | | 403 
有 六 TABLE ACCESS FULL TX 4 | | 403 
4 PARTITION RANGE AND | 1 |KEY(AP)|KEY(AP) 227 
* 5 TABLE ACCESS FULL T 6 |KEY(AP) |KEY(AP) 227 
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i - actess( "The. N=. Ni AND 21X", DTw "DE 
3 - filter(("TX"."N2"=42 AND "TX"."N1"=3)) 
5 - filter("T"."N1"=3) 


13.2.4” 散 列 和 列表 分 区 


上 一 部 分 只 介绍 了 范围 分 区 。 散 列 和 列表 分 区 也 可 以 使 用 范围 分 区 介绍 的 大 部 分 技术 。 

下 面 是 散 列 分 区 可 用 的 技术 。Pruning_hash.sql 脚 本 提供 的 执行 计划 例子 中 包含 了 这 些 操作 : 
口 PARTITION HASH SINGLE 

口 PARTITION HASH ITERATOR 

口 PARTITION HASH INLIST 

口 PARTITION HASH ALL 

口 PARTITION HASH SUBQUERY 

口 PARTITION HASH JOIN-FILTER 

口 PARTITION HASH AND 

下 面 是 列表 分 区 可 用 的 技术 。Pruning_list.sql 脚 本 提供 的 执行 计划 例子 中 包含 了 这 些 操作 : 
口 PARTITION LIST SINGLE 

口 PARTITION LIST ITERATOR 

口 PARTITION LIST INLIST 

口 PARTITION LIST ALL 

口 PARTITION LIST EMPTY 

口 PARTITION LIST OR 

口 PARTITION LIST SUBOUERY 

口 PARTITION LIST JOIN-FILTER 

口 PARTITION LIST AND 


13.2.5 ”复合 分 区 


关于 复合 分 区 没什么 可 介绍 的 。 基 本 上 ， 在 分 区 级 别 应 用 的 一 切 也 适用 于 子 分 区 。 不 过 ， 至 少 举 
个 例子 来 说 明 。 下 面 的 Test 表 是 根据 范围 (range ) 进行 分 区 ( 基于 d1 列 )， 而 子 分 区 是 根据 列表 (list ) 
进行 分 区 ( 基于 n1 列 )。 下 面 的 SQL 语句 引用 自 pruning_composite.sql 脚 本 ， 用 来 创建 该 表 。 请 注意 本 
例 中 ,也 是 每 年 48 个 分 区 : 


CREATE TABLE t ( 
id NUMBER， 
d1 DATE， 
n1 NUMBER, 
n2 NUMBER， 
n3 NUMBER, 
pad VARCHAR2(4000)， 
CONSTRAINT 七 pk PRIMARY KEY (id) 
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PARTITION BY RANGE (d1) 
SUBPARTITION BY LIST (n1) 
SUBPARTITION TEMPLATE ( 

SUBPARTITION sp 1 VALUES (1)， 

SUBPARTITION sp 2 VALUES (2), 

SUBPARTITION sp 3 VALUES (3), 

SUBPARTITION sp 4 VALUES (4) 

)( 

PARTITION t jan 2014 VALUES LESS THAN (to date('2014-02-01','YYYY-MM-DD')), 
PARTITION t feb 2014 VALUES LESS THAN (to date('2014-03-01','YYYY-MM-DD')), 
PARTITION t mar 2014 VALUES LESS THAN (to date('2014-=04-01','YYYY-MM-DD') 
PARTITION t apr 2014 VALUES LESS THAN (to date('2014-05-01','YYYY-MM-DD') 
PARTITION t may 2014 VALUES LESS THAN (to date('2014-06-01','YYYY-MM-DD')), 
PARTITION t jun 2014 VALUES LESS THAN (to date('2014-07-01','YYYY-MM-DD')), 
PARTITION t jul 2014 VALUES LESS THAN (to date('2014-08-01','YYYY-MM-DD') 
PARTITION t aug 2014 VALUES LESS THAN (to date('2014-09-01','YYYY-MM-DD')), 
PARTITION t sep 2014 VALUES LESS THAN (to date('2014-10-01','YYYY-MM-DD')), 
PARTITION t oct 2014 VALUES LESS THAN (to date('2014-11-01','YYYY-MM-DD')), 
PARTITION t nov 2014 VALUES LESS THAN (to date('2014-12-01','YYYY-MM-DD' )), 
PARTITION t dec 2014 VALUES LESS THAN (to date('2015-01-01','YYYY-MM-DD')) 


) 
图 13-9 是 Test 表 的 示意 图 。 如 果 将 其 与 之 前 的 ( 请 看 图 13-5 ) 进行 对 比 ,贯穿 整 张 表 唯一 的 不 同 就 
是 没有 任何 值 标记 子 分 区 的 位 置 。 实 际 上 ， 子 分 区 的 位 置 基于 它 的 “ 父 ” 分 区 。 


六 


n1 


d1 


司 同 辐 园 同 局 
Mar Apr May Jun Ju Aug Sep oct Nov Dec 
图 13-9 Test 表 由 每 年 48 个 分 区 组 成 
当然 ， 本 例 中 name 和 position 之 间 的 映射 也 可 以 在 数据 字典 中 找到 。 下 面 的 查询 展示 了 如 何在 
user tab partitions 和 user tab_subpartitions 视 图 中 获取 这 些 信 息 : 


SQL> SELECT subpartition name, partition position, subpartition position 
2 FROM user tab partitions p, user tab subpartitions s 

WHERE p.table name = °"T' 

AND s.table name = p.table name 

AND s.partition name = p.partition name 

ORDER BY p.partition position, s.subpartition position; 


ON 人 ww 


SUBPARTITION NAME PARTITION POSITION SUBPARTITION POSITION 
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T_JAN 2014 SP 1 1 1 
T_JAN 2014 SP 2 1 2 
T_JAN 2014 SP_3 ' 3 
T_JAN 2014 SP 4 1 4 
T_FEB 2014 SP_1 2 1 
T NOV 2014 Sp 4 11 4 
T_DEC 2014 SP 1 12 . 
T_DEC 2014 SP 2 12 2 
T_DEC 2014 SP 3 12 3 
T_DEC 2014 SP 4 12 4 


下 面 的 查询 是 在 分 区 和 子 分 区 级 别 上 都 应 用 限制 的 例子 。 操 作 在 上 一 部 分 都 介绍 过 。 操 作 1 应 用 
分 区 级 别 ， 而 操作 2 应 用 在 子 分 区 级 别 。 在 分 区 级 别 ， 访 问 分 区 1 和 7。 对 于 每 个 分 区 ， 只 访问 子 分 
区 3。 图 13-10 展 示 了 这 个 行为 。 请 注意 pstart 和 pstop 列 的 值 与 之 前 查询 数据 字典 返回 值 的 对 应 关系 : 


SELECT * FROM t WHERE n1 = 3 AND d1i < to date('2014-07-19','YYYY-MM-DD') 


| Id | Operation | Name | Starts | Pstart| Pstop | 
| 0 | SELECT STATEMENT | | 1 | | | 
| 1 | PARTITION RANGE ITERATOR| | 4 | 1 | 者 | 
| 2| PARTITION LIST SINGLE | | 7 | 3 | 3 | 
|* 3| TABLE ACCESS FULL LR 7| KEY| KEY | 


3 - filter("D1"<TO DATE(' 2014-07-19 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) 


n1 


四 回回 四 思 思 四 回 | 加 | 加 | 加 | 区 
四 回回 加 回回 加 回回 加 加 区 
Aug Sep Oct 


Nov 
图 13-10 复合 分 区 裁剪 的 表现 


d1 


13.2.6 ”设计 要 素 


正如 上 节 介 绍 的 那样 ， 查 询 优化 器 可 以 在 大 部 分 情况 下 使 用 分 区 裁剪 。 表 13-1 总 结 了 对 于 每 种 类 
型 的 分 区 方法 何 时 会 发 生 分 区 裁剪 以 及 最 常见 的 SQL 条 件 。 
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表 13-1 导致 分 区 裁剪 的 条 件 ” 


条 件 范围 列 表 散 ” 列 
Equality (=) 这 V V 
IN Vv VvV Vv 
BETWEEN、>、>=、< 或 <= Vv vV 
IS NULL 本 i 


* 不 等 值 ( 例如 != 或 <> ) 、NOT IN、1S NOT NULL 条 件 和 基于 表达 式 和 函数 的 限制 不 会 发 生 分 区 裁剪 ， 


需要 设计 分 区 表 时 ， 选择 分 区 键 和 分 区 方法 大 概 是 需要 做 出 的 最 重要 的 决定 。 目 的 是 高 效 地 利用 
分 区 裁剪 处 理 尽 可 能 多 的 SQL 语 句 。 例 如 ， 如 果 SQL 语 名 频繁 根据 天 来 处 理 数 据 ， 那 就 应 该 按照 大 来 
分 区 。 或 者 , 如 果 SQL 语 句 频繁 地 按照 国家 来 处 理 数 据 , 那 就 应 该 按照 国家 来 分 区 。 如 果 错 误 地 分 区 ， 
就 无 法 利用 分 区 裁 前 。 下 面 的 四 个 特点 是 你 的 应 用 需要 仔细 考虑 的 ， 因 为 它们 最 影响 分 区 策略 。 

(1) 哪个 列 是 限制 会 应 用 的 ， 以 及 它 的 频率 。 

(2) 这 里 保存 了 什么 类 型 的 数据 。 

(3) 限制 会 使 用 什么 SQL 条 件 。 

(4) 数据 是 否 会 定期 压缩 或 删除 以 及 处 理 的 标准 。 

第 一 和 第 四 条 是 选择 分 区 刍 的 关键 。 第 二 和 第 三 条 用 于 选择 分 区 方法 。 让 我 们 详细 讨论 一 下 。 

重点 是 要 知道 限制 会 应 用 到 哪些 列 上 ， 因 为 如 果 在 分 区 键 上 没有 限制 就 不 会 使 用 分 区 裁剪 。 换 名 
话说 ， 基 于 这 个 标准 ， 应 选择 在 有 限 的 列 数 内 应 用 限制 。 实 际 上 ， 在 不 同 的 SQL 语句 上 应 用 多 个 不 同 
的 限制 很 常见 。 因 此 ， 也 需要 知道 不 同 SQL 语 句 使 用 的 频率 。 这 样 ， 就 可 以 决定 哪个 限制 是 最 需要 优 
化 的 。 总之, 只 需要 考虑 有 弱 选择 性 的 限制 。 实际 上 ,， 强 选 择 性 的 限制 可 以 使 用 其 他 访问 结构 ( 比如 ， 
索引 ) 优化 。 

一 旦 知道 了 可 能 作为 分 区 键 的 列 ， 就 该 查看 它们 存储 的 数据 了 。 目 的 是 找 出 应 该 应 用 哪 种 分 区 方 
法 。 为 此 ， 需 要 重点 注意 两 件 事 。 第 一 ， 只 有 范围 和 列表 分 区 允许 集合 “相关 ”数据 ( 例如 ,七 月 的 
全 部 销售 额 或 所 有 欧洲 国家 ) 或 者 准确 地 映射 特定 的 值 与 特定 的 分 区 。 第 二 ， 每 种 分 区 方法 仅 适 用 于 
寺 定 类 型 的 数据 。 

口 Range 适 用 于 月 然 连续 的 值 。 典 型 实例 是 时 间 截 和 序列 生成 的 数字 。 

口 List 适 用 于 和 常见 且 有 限 的 值 。 典 型 实例 是 所 有 类 型 的 状态 信息 (例如 ，enabled 、disabled 、 

processed ) 和 描述 人 例如， 性别 、 婚 姻 状 况 ) 或 事 ( 例如 ， 国家 、 邮 编 、 货 币 、 类 别 、 格 
式 ) 的 属性 。 

口 Hash 适 用 于 不 同 的 值 超 出 分 区 数 很 多 的 所 有 类 型 数据 ( 例如 ， 客 户 编号 )。 

分 区 方法 需要 适用 于 这 种 数据 ， 也 适用 于 限制 应 用 组 成 分 区 键 的 列 。 在 表 13-1 描 述 的 与 散 列 
( hash ) 分 区 有 关 的 限制 也 应 该 考虑 到 。 此 外 , 注意 ， 即 便 技 术 上 能 够 在 列表 (list ) 分 区 表 上 使 用 范 
围 条 件 ， 这 种 不 能 使 用 分 区 裁剪 的 情况 也 很 常见 。 实 际 上 ， 列 表 分 区 表 中 的 数据 是 自然 排列 的 ， 而 
不 是 连续 的 。 

若 发 生 定期 压缩 或 删除 ， 也 应 该 考虑 它们 是 否 可 以 使 用 分 区 。 比 如 ， 删 除 或 截断 一 个 分 区 要 比 删 
除 它 包含 的 数据 快 得 多 。 这 种 策略 通常 只 用 在 范围 或 列表 分 区 上 。 

一 旦 选择 了 分 区 键 , 就 需要 确定 分 区 键 是 否 可 以 修改 ,这 样 的 修改 代表 着 移动 行 到 男 一 个 分 区 ( 与 
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删除 旧 行 然 后 在 另 一 个 分 区 里 重新 插入 的 操作 非常 相似 )， 即 改变 它 的 rowid。 通 常 ， 行 从 来 不 改变 它 
的 rowid。 因 此 ,如 果 发 生 改 变 , 不 光 要 启用 表 级 别 的 行 迁移 来 允许 数据 库 引擎 做 出 修改 ,同时 使 用 rowid 
的 应 用 也 需要 特殊 处 理 。 

最 后 一 个 注释 ,但 在 我 看 来 也 是 非常 重要 的 注释 ， 用 来 组 织 一 些 最 常见 的 错误 ， 这 些 错误 我 已 经 
在 实施 分 区 的 项 目 中 经 历 过 了 。 错 误 是 在 设计 与 实现 数据 库 与 应 用 时 并 没有 使 用 分 区 ， 而 是 在 之 后 才 
分 区 。 通 常 ， 这 种 方法 注定 会 失败 。 我 强烈 建议 在 项 目 最 初 就 计划 使 用 分 区 。 如 果 你 认为 自己 可 以 在 
之 后 轻松 地 使 用 它 ， 那 么 就 要 体验 到 “大 惊喜 ”了 。 


13.2.7 全 索引 扫描 


数据 库 引 擎 不 仅 可 以 利用 索引 提取 rowid 列 表 , 也 可 以 将 它们 作为 指针 来 读 取 表 中 对 应 的 行 , 但 它 
也 可 以 直接 读 取 索引 键 部 分 的 列 值 , 从 而 避免 根据 rowid 再 去 访问 表 。 多 亏 了 这 项 重要 的 优化 技术 , 当 
索引 包含 查询 需要 访问 的 所 有 数据 时 ,全 表 扫 描 或 全 分 区 扫描 会 由 全 索引 扫描 ( 011 index scan ) 蔡 代 。 
并 且 由 于 索引 段 通常 要 比 表 段 小 ， 用 来 减 小 逻辑 读 会 很 有 用 。 

全 索引 扫描 主要 用 于 三 种 情况 。 第 一 是 当 索 引 存 储 查询 需要 的 所 有 列 时 。 比 如 , 因为 n1 列 有 索引 ， 
下 面 的 查询 可 以 使 用 全 索引 扫描 。 下 面 的 执行 计划 证 实 了 没有 执行 访问 表 的 操作 ( 请 注意 本 节 所 有 的 
例子 都 基于 index_full scan.sql 脚 本 ): 

SELECT /*+ index(t t n1 i) */ n1 FROM 七 WHERE n1 IS NOT NULL 


| SELECT STATEMENT | | 
| INDEX FULL SCAN | TN1I | 


FS 


1 - filter("N1" IS NOT NULL) 

重点 需要 明白 这 个 执行 计划 是 合理 的 ， 因 为 WHERE 子 句 (nl IS NOT NULL ) 的 条 件 确 定 了 索引 存储 
着 所 有 需要 处 理 的 数据 ( 在 n1 列 上 的 NOT NULL 约 束 也 能 有 同样 的 效果 ， 因 为 它 确保 没有 NULL 值 插入 )。 
否则 ， 因 为 单列 B 树 索引 不 保存 NULL 值 ， 就 必须 执行 全 表 扫 描 了 。 

正如 上 面 例子 所 示 ，INDEX FULL SCAN 操 作 可 以 由 index hint 强 制 使 用 ， 根 据 它 的 结构 扫描 索引 。 这 
么 做 的 优点 是 可 以 通过 索引 键 取 回 存储 的 数据 。 缺 点 是 如 果 索 引 块 没 在 缓冲 区 缓存 中 的 话 , 那么 它 会 
使 用 单 块 读 从 数据 文件 中 读 取 它 〈 跟随 叶子 块 中 的 一 个 指针 到 下 一 个 /上 一 个 叶子 块 )。 由 于 全 索引 扫 

会 读 取 许多 数据 , 所 以 这 通常 是 低 效 的 。 要 改善 这 种 情况 下 的 性 能 , 可 以 使 用 索引 快速 全 扫描 ( index 

fast full scans )。 下 面 的 执行 计划 举例 说 明 : 

SELECT /*+ index ffs(t t ni i) */ n1 FROM 七 WHERE n1 IS NOT NULL 


| SELECT STATEMENT | | 
| INDEX FAST FULL SCAN| T Ni1 I | 


[ei 已 
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1 - filter("N1" IS NOT NULL) 

INDEX FAST FULL SCAN 操 作 可 以 通过 index ffs hint 强 制 执行 ， 它 的 特性 是 使 用 多 块 读 从 数据 文件 
中 读 取 索引 块 ， 就 像 全 表 扫 描 访问 表 一 样 。 在 扫描 期 间 ， 可 以 简单 地 丢弃 根 和 分 支 块 ， 因 为 所 有 数据 
都 保存 在 叶子 块 中 ( 通常 根 和 分 支 块 只 是 索引 段 的 一 小 部 分 ， 所 以 即使 读 取 它 们 ， 开 销 通常 也 忽略 不 
计 ) 结果 ， 并 不 考虑 访问 的 索引 结构 ， 因 此 取 回 的 数据 并 没有 根据 索引 键 来 保存 。 

第 二 个 案例 与 第 一 个 类 似 。 唯 一 的 不 同 是 数据 需要 按照 索引 中 存储 的 顺序 传输 。 例 如 ， 正 如 下 面 
的 查询 所 示 ， 因 为 指定 了 ORDER BY 子 句 ， 情 况 就 是 这 样 的 。 由 于 顺序 的 关系 ， 仅 INDEX FULL SCAN 操 作 
可 以 用 来 排序 操作 : 

SELECT /*+ index(t t n1 i) */ n1 FROM 七 WHERE n1 IS NOT NULL ORDER BY nl 


| Id | Operation | Name | 


| 0 | SELECT STATEMENT | | 
|* 1 | INDEX FULL SCAN | TN1I | 
1 - filter("N1" IS NOT NULL) 
由 于 INDEX FULL SCAN 操 作 执行 的 磁盘 IO 操作 要 比 INDEX FAST FULL SCAN 操 作 低 效 ， 前 者 只 在 排序 


时 才 会 用 到 。 


警告 nls_sort 参 数 影响 ORDER BY 操作 。 如 果 未 将 它 的 值 设置 为 binary， 那 么 仅 在 索引 列 的 数据 类 型 
不 受 NLS 设 置 (比如 ，NUMBER 和 DATE ) 影响 或 使 用 语言 索引 ( linguistic index，13.3.2 节 提供 了 
关于 这 种 索引 的 信息 ) 时 ， 索 引 全 扫描 才 可 以 用 来 优化 ORDER BY。 


默认 情况 下 ， 索 引 扫描 升序 执行 。 因 此 ，index hint 会 使 查询 优化 器 也 按照 这 种 方式 执行 。 要 明确 
指定 扫描 顺序 ， 可 以 使 用 index_asc 和 index desc hint。 下 面 的 查询 介绍 了 操作 方式 。 执 行 计划 中 显示 
了 降序 ( DESCENDING ) 扫描 : 

SELECT /*+ index desc(t t nl i) */ n1 FROM t WHERE nl IS NOT NULL ORDER BY n1 DESC 


| 0 | SELECT STATEMENT | | 
|* 1 | INDEX FULL SCAN DESCENDING| T -NL I | 


1 - filter("N1" IS NOT NULL) 
第 三 个 案例 与 count 函 数 有 关 。 如 果 查 询 包 含 它 ， 查 询 优 化 器 会 尝试 利用 索引 而 避免 全 表 扫 描 。 
下 面 的 查询 举例 说 明 。 请 注意 ，SORT AGGREGATE 操 作 是 用 来 执行 count 函 数 的 : 


SELECT /*+ index ffs(t 七 nl i) */ count(n1) FROM t 
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0 | SELECT STATEMENT | | 
| 1 | SORT AGGREGATE | | 
2 | INDEX FAST FULL SCAN| T Ni I | 


当 count 处 理 可 为 空 (nullable ) 的 列 时 ， 查 询 优 化 器 会 挑 出 任何 包含 该 列 ( 因为 NULL 值 无 法 计数 ) 
的 索引 。 当 执行 count (*) 或 针对 非 空 列 执行 count 时 ， 查 询 优化 器 能 够 选择 任何 包含 非 空 列 的 B 树 索 
引 ( 因为 只 有 在 本 例 中 索引 项 的 数目 保证 与 行 数 一 致 )， 或 任意 位 图 索引 。 因 此 ， 它 会 考虑 选择 更 小 
的 索引 。 

即使 本 节 的 例子 都 是 基于 B 树 索引 ， 大 多 数 技术 也 可 以 用 于 位 图 索引 。 只 有 两 点 不 同 。 第 一 ， 位 
图 索引 不 能 降序 扫描 ( 由 于 实现 的 限制 )。 第 二 ,位 图 索引 总 是 保存 NULL 值 。 因 此 ， 它 们 应 用 的 范围 
要 比 B 树 索引 更 大 。 以 下 查询 展示 的 例子 与 之 前 的 相似 : 


SELECT /*+ index(t t n2 i) */ n2 FROM 七 WHERE n2 IS NOT NULL 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | 

| 1 | BITMAP CONVERSION TO ROWIDS| | 
l* 2| BITMAP INDEX FULL SCAN | TN2I| 


2 - filter("N2" IS NOT NULL) 


SELECT /*+ index ffs(t t n2 i) */ n2 FROM t WHERE n2 IS NOT NULL 


| Id | Operation | Name | 


0 | SELECT STATEMENT | | 
1 | BITMAP CONVERSION TO ROWIDS | | 
2 | BITMAP INDEX FAST FULL SCAN| T N2I | 


2 - filter("N2" IS NOT NULL) 


SELECT /*+ index(t 七 n2 i) */ n2 FROM t WHERE n2 IS NOT NULL ORDER BY n2 


| Id | Operation | Name | 
0 | SELECT STATEMENT 

1 | BITMAP CONVERSION TO ROWIDS| | 
2 | BITMAP INDEX FULL SCAN | TN2I| 


2 - filter("N2" IS NOT NULL) 
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SELECT /*+ index ffs(t t n2 i) */ count(n2) FROM t 


0 | SELECT STATEMENT | | 
1 | SORT AGGREGATE | | 
2 | BITMAP CONVERSION TO ROWIDS | | 
3 | BITMAP INDEX FAST FULL SCAN| T N2 I | 
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要 高 效 处 理 强 选择 性 的 SQL 语 句 ， 数 据 需 要 通过 rowid、 索 引 或 单 表 散 列 群集 访问 "。 这 三 种 会 在 
接 下 来 的 部 分 中 介绍 。 


13.3.1 ”Rowid 访问 


访问 一 行 数据 最 高 效 的 方法 就 是 在 WHERE 子 句 中 直接 指定 它 的 rowid。 然而 , 要 利用 这 个 访问 路 径 ， 
就 必须 首先 获得 rowid, 保存 它 , 然后 在 以 后 的 访问 中 重用 它 。 换 句 话说 , 这 个 方法 只 有 在 一 行 数据 至 
少 被 访问 两 次 时 才 会 考虑 用 到 。 实 际 上 ， 当 SQL 语句 有 强 选择 性 时 ， 这 会 发 生得 很 频繁 。 例 如 ， 应 用 
使 用 手动 方式 维护 数据 ( 换 名 话说 ， 并 不 是 批量 ) 通常 会 访问 同样 的 行 至 少 两 次 ， 至 少 显示 当前 数据 
一 次 和 至 少 再 次 保存 修改 一 次 。 这 种 情况 下 ， 高 效 利用 rowid 访 问 就 有 意义 了 。 

Oracle 其 中 一 个 工具 ( SQL Developer ) 提供 了 一 个 很 好 的 例子 。 比 如 ， 当 SQL Developer 显 示 数 据 
时 ， 它 会 获取 数据 和 它 的 rowid。 比 如 scott 模 式 下 的 emp 表 ， 工 具 会 执行 以 下 查询 。 请 注意 ， 在 SELECT 

子 句 中 的 第 一 个 列 就 是 rowid: 

SELECT ROWID,"EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM", "DEPTNO" FROM "SCOTT"."EMP" 

稍 后 ，rowid 可 以 用 来 直接 访问 特定 的 行 。 例 如 ， 如 果 你 打开 Single Record View 对 话 框 ( 请 查看 
图 13-11 )， 修 改 comm 列 ， 并 且 提 交 修 改 ， 会 执行 下 面 的 SQL 语句 。 正 如 你 看 到 的 ， 工 具 会 使 用 rowid 引 
用 修改 的 行 而 不 是 主键 ( 因此 节省 了 从 主键 索引 读 取 多 个 块 的 开销 ): 

UPDATE "SCOTT"."EMP" SET COMM=:sqldevvalue WHERE ROWID = :sqldevgridrowid 

从 优化 的 角度 考虑 , 使 用 rowid 非 常 有 益 ， 因 为 可 以 直接 访问 行 , 不 需要 其 他 的 访问 结构 ( 比如 索 
引 )。 下 面 的 执行 计划 与 这 样 的 SQL 语句 有 关 : 


0 | UPDATE STATEMENT | | 
| 1 | UPDATE | EMP | 
2 | TABLE ACCESS BY USER ROWID| EMP | 


D 实际 上 ， 还 有 多 表 散 列 群 集 和 索引 群集 . 不 介绍 是 因为 在 实际 中 它们 很 少 使 用 
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图 13-11 


请 注意 ，TABLE ACCESS BY USER ROWID 操 作 专 门 用 在 当 rowid 作 为 参数 或 文字 直接 传递 时 。 在 下 一 
节 ， 你 会 看 到 当 rowid 从 索引 中 提取 出 来 ， 会 使 用 TABLE ACCESS BY INDEX ROWID 操 作 替 代 ， 访问 这 些 表 
的 效率 是 一 样 的 ; 这 两 个 操作 仅 用 来 区 分 rowid 的 来 源 。 

当 一 条 SQL 语句 通过 IN 条 件 指定 多 个 rowid 时 ， 执 行 计划 里 会 多 出 额外 的 INLIST ITERATOR 操 作 。 下 
面 的 查询 举例 说 明 。 请 注意 操作 1 ( 父 操作 ) 指 出 了 操作 2 ( 子 操作 ) 被 处 理 了 多 次 。 根据 操作 2 的 Starts 
列 值 ， 它 处 理 了 两 次 。 换 名 话说 ，emp 表 通过 rowid 访 问 了 两 次 : 

SELECT * FROM emp WHERE rowid IN ('AAADGZAAEAAAAAoAAH' , "AAADGZAAEAAAAAOAAI ') 


| Id | Operation | Name | Starts | 
0 | SELECT STATEMENT | | 1 | 
| 1| INLIST ITERATOR | | | 

2 | TABLE ACCESS BY USER ROWID| EMP | zi 


总 之 , 每 当 指定 行 被 访问 至 少 两 次 , 就 应 该 考虑 在 第 一 次 访问 时 获取 rowid, 然后 利用 它 来 进行 后 
续 的 访问 。 


13.3.2 ”索引 访问 


索引 访问 是 目前 对 强 选择 性 SQL 语句 最 常用 的 访问 路 径 。 要 使 用 它们 , 必须 在 WHERE 子 名 中 使 用 至 
少 一 个 限制 或 通过 索引 使 用 联接 条 件 。 要 这 么 做 ,不仅 索 引 列 要 提供 强 选 择 性 ， 同 时 还 要 理解 通过 索 
引 哪 种 类 型 的 条 件 才 可 以 高 效 使 用 。 数 据 库 引擎 支持 不 同类 型 的 索引 。 在 详细 介绍 B 树 索引 和 位 图 索 
引 支 持 的 访问 路 径 和 属性 前 ， 重 点 需要 说 一 下 群集 因子 ， 或 者 换 句 话说， 为 什么 数据 分 布 影响 索引 扫 
描 的 性 能 〈 请 查看 图 13-4 )。 
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注意 ”尽管 数据 库 引 擎 针对 负载 的 数据 ( 如 PDF 文 档 或 图 片 ) 支持 域 索 引 ， 但 在 本 书 中 不 作 介绍 。 更 
多 的 信息 请 参考 Oracle 数 据 库 官方 文档 。 


1. 群集 因子 


正如 第 8 章 中 介绍 的 那样 ， 和 群集 因子 指示 有 多 少 相 邻 的 索引 键 不 引用 表 中 相同 的 数据 块 (位 图 索 
引 是 例外 ， 因 为 总 是 会 将 其 群集 因子 设置 为 索引 中 键 的 数量 )。 下 面 一 张 记忆 图 像 或 许 会 有 帮助 : 如 
果 整 张 表 通 过 索引 访问 并 且 在 缓冲 区 缓存 中 有 单独 一 个 缓冲 区 保存 着 数据 块 , 那么 群集 因子 是 对 表 执 
行 物理 读 的 数量 。 例 如 ， 图 13-12 展 示 索 引 的 群集 因子 是 10( 请 注意 ， 总 共有 12 行 ， 且 仅 有 2 个 高 完 显 
示 的 相 邻 索引 键 引用 相同 的 数据 块 )。 
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图 13-12 ”索引 块 与 数据 块 之 间 的 关系 
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下 面 的 PL/SQL 函 数 可 以 在 clustering factor.sql 肢 本 中 找到 , 举例 说 明了 它 是 如 何 计算 的 。 请 注 
意 ， 这 个 隐 数 仅 能 使 用 在 单行 B 树 索引 上 : 


CREATE OR REPLACE FUNCTION clustering factor ( 


p_owner IN VARCHAR2, 
p_table name IN VARCHAR2, 
P_column_name IN VARCHAR2 


~ 一 


] cursor 


1] clustering factor BINARY INTEGER : 


1 block nr 


] previous block nr BINARY INTEGER : 


J ile nr 


RETURN NUMBER IS 


SYS_ REFCURSOR; 


= 


BINARY INTEGER : 


=- 


DS SS 
， - 


中 外 站 外 


BINARY_INTEGER : 


~ 


13 
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1 previous file nr BINARY INTEGER := 0; 
BEGIN 
OPEN 1 cursor FOR 
"SELECT dbms rowid.rowid block number(rowid) block nr, '|| 
dbms rowid.rowid to absolute fno(rowid, "'"|| 
"| 


p_owner|| 3 | 
) file nr | 


p_table name||"' 
"FROM '||p owner||'.'||p table name||' '|| 
“WHERE '||p_column name||" IS NOT NULL “| 
"ORDER BY ' || p_column name ||', rowid'; 
LOOP 


FETCH 1 cursor INTO 1 block nr, 1 file nr; 
EXIT WHEN 1 cursor%NOTFOUND; 
IF (1 previous block nr <> 1 block nr OR 1 previous file nr <> 1 file nr) 
THEN 
1 clustering factor := 1 clustering factor + 1; 

END IF; 
1 previous block nr := 1 block nr; 
1 previous file nr :=: 1 file nr; 

END LOOP; 

CLOSE 1 ‘cuysor; 

RETURN 1 clustering factor; 

END; 


请 注意 , 它 生成 的 值 与 数据 字典 中 统计 信息 的 匹配 : 
SQL> SELECT i.index name, i.clustering factor， 
clustering factor(user, i.table name, ic.column name) AS my_ clus fact 


3 FROM user indexes i, user ind columns ic 
4 WHERE i.table name = "T' 
5 
6 


[i 


AND i.index name = ic.index_ name 
ORDER BY i.index name; 


INDEX NAME CLUSTERING FACTOR MY_ CLUS FACT 


群集 因子 计算 是 翡 观 的 

dbms_stats 包 使 用 的 算法 用 来 计算 群集 因子 是 相当 悲观 的 。 

实际 上 ， 算 法 考虑 在 索引 范围 扫描 期 间 ， 只 有 块 被 缓存 中 的 前 索引 键 引 用 到 。 实际 上 ， 早 期 的 
多 个 块 可 能 留 在 缓存 中 。 结 果 ， 和 群集 因子 无 法 准确 描述 真实 的 数据 分 布 并 不 罕见 

为 了 防止 或 者 解决 关于 悲观 计算 的 问题 ， 从 11.2.0.4 版 本 开始 ( 或 者 安装 了 解决 bug 13262857 的 
补丁 之 后 ) 可 以 通过 dbms_ stats 包 来 设置 table cached blocks。 它 的 值 从 1 至 255， 用 来 指定 会 有 多 
少 个 块 期 望 被 缓存 。 默 认 值 是 1。 即 使 建议 值 总 是 很 难 给 出 ， 但 好 像 任何 大 于 1 的 值 都 会 使 群集 因子 
更 可 靠 。 实 际 上 ， 默 认 值 实在 是 太 莫 观 了 。 此 外 ，dbms stats.auto table cached blocks 的 值 指定 
使 用 255、 表 块 的 1% 或 缓冲 区 缓存 的 0.1%， 会 选择 它们 之 中 最 小 的 那个 
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从 性 能 的 观点 看 ， 应 该 避免 基于 行 的 处 理 。 这 在 本 章 之 前 介绍 过 ， 多 亏 了 行 预 取 ， 数 据 库 引 擎 也 
会 尽 可 能 地 避免 它 。 实 际 上 ， 当 必须 从 同样 的 块 中 取出 多 行 时 ， 在 单个 访问 中 所 有 的 行 都 会 提取 出 来 
而 不 是 每 取出 一 行 都 会 访问 一 次 块 ( 即 ， 逻 辑 读 )。 要 强调 这 一 点 ， 让 我 们 来 看 一 个 基于 
clustering_factor.sql 脚 本 的 例子 。 下 面 是 由 脚本 创建 的 Test 表 : 


SQL> CREATE TABLE 七 ( 
2 id NUMBER， 
3 val NUMBER, 
4 pad VARCHAR2(4000), 
3 CONSTRAINT t pk PRIMARY KEY (id) 
6 )» 


SQL> INSERT INTO t 
2 SELECT rownum, dbms random.value, dbms random.string('p',500) 
3 FROM dual 
4 CONNECT BY level <= 1000; 


由 于 id 列 的 值 是 按照 递增 顺序 插入 的 ， 索 引 支 持 主键 的 群集 因子 接近 表 中 的 块 数 。 换 句 话 说， 这 
是 好 事 : 
SQL> SELECT blocks, num rows 


2 FROM user tables 
3 WHERE table name = "TT'; 


BLOCKS NUM ROWS 


SQL> SELECT blevel, leaf blocks, clustering factor 
2 FROM user indexes 
3 WHERE index name = 'T_ PK'; 


BLEVEL LEAF BLOCKS CLUSTERING FACTOR 
当 整 张 表 通过 主键 访问 时 ( 使 用 hint 强 制 执行 这 样 的 执行 计划 ), 查看 执行 的 逻辑 读数 会 很 有 帮助 。 
第 一 个 实验 将 行 预 取 设置 为 2。 因 此 ， 数 据 库 引擎 至 少 执 行 500 次 调用 来 取 回 1000 行 。 可 以 通过 查看 逻 
辑 读 数 ( Buffers 列 ) 来 证 实 这 种 行为 : 索引 上 503， 表 上 539 ( 1042-503 )。 多 亏 了 群集 因子 ， 基 本 上 
对 于 每 次 调用 ,都 会 从 索引 块 上 提取 两 个 rowid, 并 且 几 乎 每 次 它们 的 数据 也 会 在 相同 的 数据 块 上 找到 ; 六 
13 


SOL> set arraysize 2 


SQL> SELECT /*+ index(t t pk) */ * FROM t; 


| Id | Operation | Name | Starts | A-Rows | Buffers 

| 0 | SELECT STATEMENT | | 1| 1000| 1042 | 
| 1 | TABLE ACCESS BY INDEX ROWID | T | 1| 1000| 1042 | 
| 2| INDEX FULL SCAN | Ek | 1| 1000 | 503 | 
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第 二 个 实验 将 行 预 取 设 置 为 100。 因 此 ， 数 据 库 引 敬 执行 10 次 调用 就 足以 取 回 所 有 行 。 这 个 行为 
也 可 以 通过 逻辑 读数 来 证 实 : 索引 上 是 13, 表 上 是 87 ( 100-13 )。 基 本 上 ， 对 于 每 次 调用 ，100 个 rowid 
从 索引 块 中 提取 出 来 ， 而 它们 表 中 相应 的 行 通常 也 会 在 相同 的 块 中 找到 ， 并 且 只 需要 访问 一 次 : 


SQOL> set arraysize 100 


SQL> SELECT /*+ index(t t pk) */ * FROM t; 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 1 | wooo | 100 | 
| 1 | TABLE ACCESS BY INDEX ROWID | T | 1| 41000 | 100 | 
| 2| INDEX FULL SCAN | TPK | 1| 1000 | 13 | 


现在 让 我 们 使 用 更 高 的 群集 因子 执行 相同 的 实验 。 要 完成 这 个 实验 ， 会 将 基于 随机 值 的 ORDER BY 
子 句 添加 到 INSERT 语 句 中 ， 用 来 将 数据 存 信 表 中 。 唯 一 改变 的 统计 信息 就 是 群集 因子 。 请 注意 ， 这 个 
值 接近 行 数 。 换 句 话说， 这 不 是 好 事 : 

SQL> TRUNCATE TABLE t; 


SQL> INSERT INTO 七 
2 SELECT rownum, dbms random.value，dbms random.string('p',500) 
3 FROM dual 
4 CONNECT BY level <= 1000 
5 ORDER BY dbms_random.value; 


SQL> SELECT blocks， Num_rows 
2 FROM user tables 
3 WHERE table name = 'T'; 


BLOCKS NUM ROWS 


SQL> SELECT blevel, leaf blocks, clustering factor 
2 FROM user indexes 
3 WHERE index name = 'T_PK'; 


BLEVEL LEAF BLOCKS CLUSTERING FACTOR 


下 面 是 两 个 实验 的 逻辑 读数 。 一 方面 ， 两 个 实验 中 索引 上 的 逻辑 读数 都 没有 改变 。 因 为 索引 上 以 
完全 相同 的 顺序 存储 着 相同 的 键 ( 只 有 对 应 的 rowid 不 同 )。 另 一 方面 ， 两 个 实验 在 表 上 的 逻辑 读数 都 
接近 行 数 。 因 为 索引 上 临近 的 rowid 几 乎 不 会 涉及 相同 的 块 : 


SQL> set arraysize 2 


SQL> SELECT /*+ index(t t pk) */ * FROM t; 
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| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | 1| 1000 | 1499 | 
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1| 1000| 1499 | 
| 2| INDEX FULL SCAN | TPk | 1 | 1000 | 502 | 
SOL> set arraysize 100 

| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 1| 1000 | 1003 | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 1| 1000 | 4003 | 
| 2| INDEX FULL SCAN | T_PK | 1 | 1000 | 13 | 


总 之 , 使 用 高 群集 因子 的 行 预 取 更 低 效 ， 因 此 会 执行 更 高 的 逻辑 读数 。 群 集 因子 对 资源 消耗 的 影 
响 非常 高 ， 以 至 于 查询 优化 器 ( 在 第 9 章 中 介绍 过 ， 尤 其 是 公式 9-4 ) 使 用 群集 因子 计算 索引 访问 相关 
的 成 本 ， 这 通常 是 计算 的 主要 因素 。 


2. B 树 索引 与 位 图 索引 
简单 来 说 ， 有 些 情况 下 只 会 使 用 B 树 索引 。 如 果 不 是 这 些 情 况 ,， 大 多 数 情况 下 也 会 使 用 位 图 索引 。 
表 13-2 总 结 了 决定 使 用 B 树 索引 和 位 图 索引 时 需要 考虑 的 特性 。 


表 13-2 ” 仅 支 持 B 树 索引 和 位 图 索引 的 重要 特性 


特 性 B 树 索引 位 图 索引 
主键 和 唯一 键 V 
行 级 锁 V 
多 个 索引 的 高 效 组 合 v 
分 区 表 上 的 全 局 索引 和 非 分 区 索引 Vv 


注意 位 图 索引 仅 在 企业 版 中 可 用 。 


位 图 索引 的 使 用 主要 有 两 种 情况 限制 。 第 一 ， 只 有 B 树 索引 可 以 使 用 主键 和 唯一 键 。 这 通常 没有 
选择 。 第 二 ,只 有 B 树 索引 支持 行 级 锁 , 因为 索引 ( B 树 索引 和 位 图 索引 ) 中 的 锁 是 在 内 部 设置 索引 项 。 
因为 单个 位 图 索引 项 可 能 指向 数 千 行 , 位 图 索引 列 的 修改 可 能 会 阻止 其 他 几 千 行 (引用 自 相同 索引 项 ) 
的 修改 ， 这 会 在 很 大 程度 上 抑制 可 扩展 性 。 另 一 个 位 图 索引 的 劣势 是 ， 当 修改 它们 时 ， 数据库 引擎 会 
生成 更 多 的 redo。 这 是 因为 ， 大 多 数 情况 下 位 图 索引 键 要 比 B 树 索引 键 大 。 
请 注意 索引 的 选择 性 或 不 重复 的 键 数 与 选择 B 树 索引 或 位 图 索引 无 关 。 尽 管 如 此 ， 许 多 关于 位 图 
索引 的 书 和 文章 还 是 包含 以 下 建议 : 
位 图 索引 适用 于 低 基 数 不 常 修改 的 数据 ， 当 一 列 不 重复 值 的 数量 与 整个 行 数 相 比 低 很 多 
时 ， 数 据 具 有 低 基 数 。 
通过 压缩 技术 ， 这 些 索 引 可 以 使 用 最 小 IO 生成 许多 rowid。 当 使 用 的 查询 中 包含 以 下 特 
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征 时 ， 位 图 索引 可 以 提供 特别 有 用 的 访问 路 径 : 
口 WHERE 子 名 中 的 多 个 条 件 

口 在 低 基 数列 上 的 AND 和 OR 操 作 

口 COUNT 函 数 

口 为 空 值 选择 的 谓词 


Oracle Database SOL Tuning Gude 12c Release 1 
老实 说 从 我 的 观点 来 看 ， 这 样 的 信息 至 少 有 些 误导 。 事 实 上 ， 弱 选择 性 的 SQL 语 句 不 可 能 通过 从 
索引 获取 rowid 列 表 来 高 效 执行 这 是 因为 对 于 B 树 索引 和 位 图 索引 来 说 , 用 来 建立 rowid 列 表 的 逻辑 读 
的 数量 要 比 使 用 它们 访问 表 的 逻辑 读 的 数量 少 得 多 。 因 此 , 无 论 是 B 树 索引 还 是 位 图 索引 ,大 部 分 时 间 
都 用 来 读 表 了 。 这 就 是 说 , 位 图 索引 要 比 具 有 较 少 数量 的 非 重复 键 的 B 树 索引 表现 得 更 好 ( 请 注意 在 摘 
录 中 ,术语 基数 ( cardinality ) 与 本 书 中 使 用 的 有 不 同 的 含义 ), 但 是 请 注意 , 更 好 并 不 代表 高 效 。 例如 ， 
一 个 糟糕 的 产品 并 不 好 ， 因 为 它 仅 仅 比 一 个 非常 糟 的 产品 更 好 。 组 合 位 图 索引 或 许 非常 高 效 ， 但 是 建 
立 rowid 列 表 仅 是 开始 。 之 后 仍然 需要 访问 行 。 我 也 应 该 提 到 0OR。 如 果 你 能 想到 ， 就 会 意识 到 使 用 OR 组 
合 多 个 非 选择 性 条 件 只 会 带 来 更 弱 的 选择 性 ， 而 如 果 想 高 效 使 用 索引 ， 那 么 目标 应 该 是 提高 选择 性 。 


提示 需要 在 B 树 索引 和 位 图 索引 中 选择 时 ,请 忽略 选择 性 和 基数 。 


除了 表 13-2 总 结 的 不 同 之 外 ， 当 处 理 相同 的 SQL 条 件 时 ，B 树 索引 和 位 图 索引 并 未 显示 相同 的 效 
率 。 实 际 上 ， 位 图 索引 通常 更 强大 些 。 表 13-3 总 结 两 种 类 型 的 索引 ， 以 及 它们 处 理 不 同类 型 条 件 的 能 
力 。 下 一 节 的 目标 是 提供 一 些 关 于 它们 的 例子 。 我 也 会 介绍 不 同 的 性 能 和 限制 


表 13-3 ”可 能 导致 Index Unique/Range Scan 的 条 件 


条 件 B 树 索引 位 图 索引 
Equality (=) Vv v 
IS NULL of 了 
Range (BETWEEN、>、>=、< 和 <=) We ¥ 
IN vV V 
LIKE 了 7 
Inequality (!= 和 <>) 和 IS NOT NULL a 


* 不 适用 于 单列 索引 ; 仅 在 另 一 个 条 件 导 致 索引 范围 扫描 或 NULL 值 存储 在 索引 中 时 适用 于 复合 索引 。 
+ 仅 在 多 个 位 图 索引 组 合 时 适用 。 


接 下 来 的 部 分 中 许多 例子 都 是 基于 conditions.sq] 脚 本 。Test 表 和 它 的 索引 使 用 以 下 SQL 语句 创建 : 


CREATE TABLE t ( 

id NUMBER， 
d1 DATE， 

n1 NUMBER, 
n2 NUMBER, 
n3 NUMBER, 
n4 NUMBER, 
n5 NUMBER, 
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n6 NUMBER， 

C1 VARCHAR2(20), 

c2 VARCHAR2(20), 

pad VARCHAR2(4000), 

CONSTRAINT t pk PRIMARY KEY (id) 


庆 

CREATE INDEX i nl ON t (n1); 

CREATE INDEX i_n2 ON t (n2); 

CREATE INDEX i_n3 ON t (n3); 

CREATE INDEX i n123 ON t (n1, n2, n3); 
CREATE BITMAP INDEX i n4 ON t (n4); 
CREATE BITMAP INDEX i n5 ON t (n5); 
CREATE BITMAP INDEX i n6 ON t (n6); 
CREATE INDEX i c1 ON t (c1); 


CREATE BITMAP INDEX i c2 ON t (c2); 


3. 等 式 条 件 与 B 树 索引 

使 用 B 树 索引 时 ， 等 式 条 件 会 使 用 其 中 一 个 操作 执行 。 第 一 ，INDEX UNIQUE SCAN， 专 门 用 来 使 用 
唯一 索引 。 顾 名 思 义 ， 使 用 它 最 多 返回 一 个 rowid。 下 面 的 查询 举例 说 明 。 执 行 计 划 证 实 通过 操作 2 访 
问 谓词 ， 在 id 列 上 的 条 件 使 用 了 t_pk 索 引 。 接 着 ， 操 作 1 使 用 从 索引 中 提取 的 rowid 来 访问 表 。 这 是 通 
过 TABLE ACCESS BY INDEX RONID 操 作 来 完成 的 。 请 注意 这 两 个 操作 都 是 只 执行 一 次 : 

SELECT /*+ index(t) */ * FROM t WHERE id = 6 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1 | 1 | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 1 | 1 | 
|* 2 | INDEX UNIOUE SCAN | Tpk | 4 1 1 


2 - access("ID"=6) 


注意 本 节 内 容 ， 要 强制 索引 扫描 ， 只 需 指 定 表 名 来 使 用 index hint。 当 这 么 使 用 时 ， 查 询 优化 器 可 
以 在 所 有 可 用 的 索引 中 任意 选择 。 在 所 有 例子 中 ， 单 谓词 存在 于 WHERE 子 名 中。 为 此 ， 查 询 优 
化 器 总 是 选择 基于 引用 谓词 列 上 的 索引 。 


第 二 ，INDEX RANGE SCAN ， 用 来 使 用 非 唯一 索引 。 这 个 操作 与 之 前 的 唯一 区 别 就 是 它 可 以 提取 许 
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多 rowid ( 本 例 为 527 )， 而 不 仅 是 一 个 : 
SELECT /*+ index asc(t) */ * FROM 七 WHERE n1 = 6 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | 1| 527 | 
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1| 527 | 
|* 2 | INDEX RANGE SCAN 本 二 二 | 下 527 | 


2 - access("N1"=6) 
从 12.1 版 本 开始 ， 基 于 从 索引 范围 扫描 返回 的 rowid 来 访问 表 的 操作 是 TABLE ACCESS BY INDEX ROWID 
BATCHED。 这 个 操作 的 目的 是 利用 访问 多 个 rowid 来 优化 表 访 问 。 下 面 的 例子 展示 的 执行 计划 与 上 一 个 
查询 一 致 : 


SELECT /*+ index asc(t) */ * FROM t WHERE n1 = 6 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 527 | 
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| T | 1 | 527 | 
| 率 痘 | INDEX RANGE SCAN | IN1 | yal 527 | 


2 - access("N1"=6) 
默认 情况 下 ， 索 引 扫 描 按 照 升序 执行 。 因此，index hint 命 令 优化 器 也 按照 这 个 顺序 执行 。 要 明确 
指定 扫描 顺序 ， 可 以 使 用 index_ asc 和 index_desc hint。 下 面 的 查询 举例 说 明 。 在 执行 计划 中 ， 降 序 扫 
描 显 示 为 INDEX RANGE SCAN DESCENDING 操 作 : 
SELECT /*+ index desc(t) */ * FROM t WHERE n1 = 6 


| Id | Operation | Name | Starts | A-Rows | 


0 | SELECT STATEMENT | 1 | 
1 | TABLE ACCESS BY INDEX ROWID | T | 下 | | 
2 | INDEX RANGE SCAN DESCENDING| I_N1 | 1 | 


2 - access("N1"=6) 
filter("N1"=6) 
请 注意 ，INDEX RANGE SCAN 和 INDEX RANGE SCAN DESCENDING 返 回 相 同 的 数据 。 只 是 顺序 不 同 。 稍 
后 ， 在 范围 条 件 部 分 会 介绍 何 时 会 用 到 这 样 的 访问 路 径 。 


4. 等 式 条 件 与 位 图 索引 
使 用 位 图 索引 时 , 等 式 条 件 会 使 用 三 个 操作 。 按照 执行 的 次 序 , 第 一 个 操作 是 BITMAP INDEX SINGLE 
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VALUE， 它 会 扫描 索引 并 应 用 限制 。 顾名思义 ， 这 个 操作 寻找 单个 值 。 第 二 个 操作 是 BITMAP CONVERSION 
TO ROWIDS， 通 过 第 一 个 操作 获得 的 内 容 转 换 成 rowid 列 表 。 第 三 个 操作 使 用 第 二 个 操作 建立 的 rowid 列 
表 来 访问 表 。 请 注意 这 三 个 操作 都 只 执行 一 次 : 

SELECT /*+ index(t i n4) */ * FROM t WHERE n4 = 6 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | tl 271| 
| 1 | TABLE ACCESS BY INDEX ROWID | T | gd | Sa 
| 2| BITMAP CONVERSION TO ROWIDS | | bo 527 | 
| BITMAP INDEX SINGLE VALUE | I N4 | | 1 


3 - access("N4"=6) 


警告 ”在 这 一 节 里 ， 要 强制 索引 扫描 ， 只 需 指 定 表 名 来 使 用 index hint。 换 和 句 话说 ，hint 指 定 了 该 使 用 
哪个 索引 。 当 这 么 使 用 时 ,hint 只 有 在 同名 索引 存在 时 才 有 效 。 由 于 索引 名 很 容易 改变 (例如 ， 
使 用 ALTER INDEX RENAME 语 句 )， 所 以 实际 上 hint 也 容易 发 生 语法 错误 导致 其 失效 。 


对 于 B 树 索引 来 说 , 从 12.1 版 本 开始 , 使 用 索引 返回 的 多 个 rowid 访 问 表 的 操作 是 : TABLE ACCESS BY 
INDEX RONID BATCHED。 下 面 的 例子 展示 的 执行 计划 与 上 一 个 查询 一 致 : 
SELECT /*+ index(t i n4) */ * FROM t WHERE n4 = 6 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1 | 527 | 
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| T | LE | 527 | 
| 2| BITMAP CONVERSION TO ROWIDS | | 1 | S27 | 
|* 3 | BITMAP INDEX SINGLE VALUE | 工 N4 1 1 | 1 | 


3 - access("N4"=6) 


5. IS NULL 条 件 与 B 树 索引 
使 用 B 树 索引 , IS NULL 条 件 仅 能 通过 复合 B 树 索引 来 使 用 , 如 果 其 他 条 件 导 致 索引 范围 扫描 或 NULL 3 


值 保存 在 索引 中 ， 那 么 这 两 个 条 件 至 少 需要 满足 一 个 ， 因 为 仅 有 NULL 值 的 索引 项 既 不 存在 于 单列 索引 
中 也 不 存在 于 组 合 索 引 中 。 

下 面 的 查询 举例 说 明 指 定 两 个 条 件 的 案例 。 执 行 计划 证 实 通过 访问 操作 2 的 谓词 ，n2 列 上 的 条 件 
使 用 i_n123 索 引 。 同 时 请 注意 操作 2 仅 返 回 了 5 行 ， 然 而 在 “等 式 条 件 与 B 树 索引 ”部 分 ， 并 没有 n2 IS 
NULL 限 制 ， 范 围 扫描 返回 了 527 行 : 

SELECT /*+ index(t) */ * FROM 七 WHERE nl = 6 AND n2 IS NULL 
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| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | "| 5 | 
| 1 | TABLE ACCESS BY INDEX ROWID| T | 珊 | 5 | 
|* 2 | INDEX RANGE SCAN | I N123 | 业 中 5 


2 - access("N1"=6 AND "N2" IS NULL) 
正如 下 面 例 子 所 示 ， 同 样 的 执行 计划 也 用 于 当 IS NULL 条 件 指定 在 索引 前 导 列 上 时 : 
SELECT /*+ index(t) */ * FROM 七 WHERE nl IS NULL AND n2 = 8 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1 | 4 | 
| 1 | TABLE ACCESS BY INDEX ROWID| T | :| 4 | 
|* 2 | INDEX RANGE SCAN | I N123 | 1 | 4 | 


2 - access("N1" IS NULL AND "N2"=8) 
filter("N2"=8) 


其 他 IS NULL 条 件 可 以 通过 复合 B 树 索引 应 用 的 情况 ， 是 当 NULL 值 保存 在 索引 中 时 。 下 面 的 查询 就 
是 这 种 情况 。 请 注意 ， 由 于 n2 的 IS NOT NULL 条 件 ， 它 保证 了 所 有 满足 NHERE 子 句 的 行 都 会 在 i_n123 索 
引 中 有 对 应 的 索引 项 。 因 此 ， 可 以 使 用 索引 范围 扫描 来 找到 它们 : 


SELECT /*+ index(t) */ * FROM t WHERE n1 IS NULL. AND n2 IS NOT NULL 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1| 521| 
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1| 5 | 
|* 2 | INDEX RANGE SCAN | I N123 | 1 | 521 | 


2 - access("N1" IS NULL) 
filter("N2" IS NOT NULL) 


当 至 少 有 一 列 为 非 空 时 ，NULL 值 也 会 存储 在 组 合 索引 中 。 一 个 特别 的 案例 满足 这 个 条 件 ， 索 引 创 
建 在 可 为 空 的 列 和 常数 上 。 不 用 说 也 知道 这 是 圈套 。 但 是 在 某 些 情况 下 ， 这 是 很 有 用 的 。 下 面 的 索引 
举例 说 明 (请 注意 ， 可 以 使 用 另 一 个 值 来 代替 0 ): 


CREATE INDEX i n1 nn ON t (n1, 0) 
使 用 这 样 的 索引 ， 类 似 以 下 的 查询 能 够 执行 索引 范围 扫描 : 
SELECT /*+ index(t) */ * FROM t WHERE nl IS NULL 


| Id | Operation | Name | Starts | E-Rows | A-Rows | 
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| 0 | SELECT STATEMENT | | 1 | | = B26 | 
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1| 56| 526 | 
|* 2 | INDEX RANGE SCAN | INLNN| 1| 526| 526 | 


2 - access("N1" IS NULL) 
然而 ,单列 索引 不 能 用 于 IS NULL 条 件 。 这 是 因为 NULL 值 无 法 存储 在 索引 中 。 因 此 ， 在 本 例 中 查询 
优化 器 无 法 利用 索引 范围 扫描 。 即 使 尝试 强制 使 用 index hint， 也 会 执行 全 表 扫 描 或 全 索引 扫描 : 


SELECT /*+ index(t i n1) */ * FROM t WHERE n4 IS NULL 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1| 526 | 
|* 1 | TABLE ACCESS FULL|T | 1| 526 | 


1 - filter("N1" IS NULL) 
6. IS NULL 条 件 与 位 图 索引 
使 用 位 图 索引 ，IS NULL 条 件 使 用 与 等 式 条 件 相 同 的 方法 执行 。 因 为 位 图 索引 存储 NULL 值 的 方式 与 
存储 其 他 值 的 方式 一 致 : 


SELECT /*+ index(t i n4) */ * FROM 七 WHERE n4 IS NULL 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | 1| 526 | 
| 1 | TABLE ACCESS BY INDEX ROWID | T | 1| 526| 
| 2| BITMAP CONVERSION TO ROWIDS| | 1| 526| 
|* 3 | BITMAP INDEX SINGLE VALUE | I N4 | 1 1 | 


3 - access("N4" IS NULL) 
7. 范围 条 件 与 B 树 索引 
使 用 B 树 索引 ， 范 围 条 件 使 用 与 等 式 条 件 在 非 唯一 索引 上 相同 的 执行 方法 ， 或 者 换 名 话说， 使 用 
INDEX RANGE SCAN 操 作 。 对 于 范围 条 件 来 说 ， 与 其 索引 类 型 ( 即 其 独特 性 ) 无 关 。 由 于 是 范围 扫 摘 ， 
总 是 可 以 返回 多 个 rowid。 例 如 ， 下 面 的 查询 显示 范围 条 件 应 用 在 由 主键 构成 的 列 上 : 
SELECT /*+ index(t (t.id)) */ * FROM 七 WHERE id BETWEEN 6 AND 19 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1 | 14 | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 1 | 14 | 
|* 2 | INDEX RANGE SCAN | TPk | 1 | 14 | 
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2 - access("ID">=6 AND "ID"<=19) 


注意 在 这 一 节 里 ， 通 过 指定 表 名 以 及 在 哪 一 列 创建 索引 ， 来 使 用 多 个 hint 强 制 索引 扫描 。 对 比 这 种 
语法 与 指定 索引 名 的 方法 ， 优 势 在 于 hint 并 不 需要 依赖 索引 名 .这 让 hint 的 可 靠 性 更 强 。 它 的 
劣势 是 hint 不 能 保证 查询 优化 器 总 是 选择 相同 的 索引 


正如 在 上 一 部 分 提 到 的 那样 ， 索 引 扫 描 默 认 是 升序 执行 的 。 这 意味 着 将 使 用 二 进 制 比 较 ( 稍 后 会 
在 “语言 索引 ”部 分 提供 关于 不 同类 型 的 比较 以 及 如 何 处 理 它们 的 信息 ) 的 ORDER BY 作为 范围 条 件 应 
用 于 相同 的 列 时 ， 已 对 结果 集 进 行 排序 。 因 此 ， 就 不 需要 再 执行 排序 了 。 然 而 ， 当 ORDER BY 需要 降序 
排列 时 ， 就 需要 明确 执行 排序 ， 正 如 下 面 的 查询 所 示 。 排 序 由 操作 1 SORT ORDER BY 执行 。 请 注意 索引 
扫描 被 index_asc hint 强 制 升序 扫描 : 


SELECT /*+ index asc(t (t.id)) *#/ * FROM 七 WHERE id BETWEEN 6 AND 19 ORDER BY id DESC 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1 | 14 | 
| 1| SORT ORDER BY | | 1 | 14 | 
| 有 | TABLE ACCESS BY INDEX ROWID| T | 大 | 14 | 
|* 3 | INDEX RANGE SCAN | TPK | 1 | 14 | 


3 - access("ID">=6 AND "ID"<=19) 
同样 的 查询 可 以 利用 降序 索引 扫描 来 避免 强制 排序 。 下 面 的 例子 ， 执 行 计划 中 已 经 不 存在 SORT 
ORDER BY 操作 了 : 
SELECT /*+ index desc(t (t.id)) */ * FROM t WHERE id BETWEEN 6 AND 19 ORDER BY id DESC 


| Id | Operation | Name | Starts | E-Rows | A-Rows | 


0 | SELECT STATEMENT | 1 | 
1 | TABLE ACCESS BY INDEX ROWID | TT | "| 15 | 14 | 
2 | INDEX RANGE SCAN DESCENDING| T_PK | 1] 


2 - access("ID"<=19 AND "ID">=6) 


8. 范围 条 件 与 位 图 索引 

使 用 位 图 索引 ,范围 条 件 使 用 与 等 式 条 件 类 似 的 方法 执行 ,唯一 不 同 的 是 ,BITMAP INDEX RANGE SCAN 
操作 用 来 替代 BITMAP INDEX SINGLE VALUE 操 作 : 

SELECT /*+ index(t (t.n4)) */ * FROM t WHERE n4 BETWEEN 6 AND 19 


| Id | Operation | Name | Starts | A-Rows | 
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| 0 | SELECT STATEMENT | | 1| 6840 | 
| 1| TABLE ACCESS BY INDEX ROWID | T | 1 | 6840 | 
| 2| BITMAP CONVERSION TO ROWIDS| | 1 | 6840 | 
|* 3| BITMAP INDEX RANGE SCAN | IN4| 了 | 13 | 


3 - access("N4">=6 AND "N4"<=19) 


对 于 位 图 索引 来 说 ， 没 有 升序 和 降序 扫描 的 概念 ， 因 此 无 法 避免 和 优化 ORDER BY 操作 。 


9. IN 条 件 

IN 条 件 并 没有 指定 的 访问 路 径 。 相反 , 在 执行 计划 中 , 由 于 IN 条 件 被 执行 了 多 次 ，INLIST ITERATOR 
拥 作 指出 执行 计划 的 其 中 一 部 分 。 下 面 的 三 个 查询 展示 了 根据 索引 类 型 来 使 用 索引 扫描 的 操作 。 第 一 
个 是 唯一 索引 ， 第 二 个 是 非 唯一 B 树 索引 ， 第 三 个 是 位 图 索引 。 基 本 上 ，IN 条 件 就 是 一 系列 的 等 式 条 
件 。 请 注意 ， 操 作 相关 的 索引 和 表 访 问 针 对 IN 列 表 (请 看 starts 列 ) 中 的 每 个 值 只 执行 一 次 : 

SELECT /*+ index(t t pk) */ * FROM t WHERE id IN (6, 8, 19, 28) 


| Id | Operation | Name | Starts | A-Rows | 


0 | SELECT STATEMENT | 
1 | INLIST ITERATOR | 
2 | TABLE ACCESS BY INDEX ROWID| 
3 | INDEX UNIOUE SCAN | 


3 - access(("ID"=6 OR "1D"=8 OR "ID"=19 OR “ID"=28)) 
SELECT /*+ index(t i n1) */ * FROM 七 WHERE nl IN (6, 8, 19, 28) 


| Id | Operation | Name | Starts | E-Rows | A-Rows | 
| 0 | SELECT STATEMENT | | 1 | | 1579 | 
| 1 | INLIST ITERATOR | | 1 | | 1579 | 
| 2| TABLE ACCESS BY INDEX ROWID| T | 4| 1710 | 1579 | 
js 总 | INDEX RANGE SCAN | IN1| 4| 1710 | 1579 | 


3 = access(("N1"=6 OR "N1"=8 OR "N1"=19 OR "N1"=28)) 


SELECT /*+ index(t i n4) */ * FROM t WHERE n4 IN (6, 8, 19, 28) 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | | 汪 笨 :| 
| 1 | INLIST ITERATOR | | 4 | | 
| 2| TABLE ACCESS BY INDEX ROWID |T | 4| 1579 | 
| | BITMAP CONVERSION TO ROWIDS| | 4| 1579 | 
l* 4 | BITMAP INDEX SINGLE VALUE | I N4 | 4 | 3 | 
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4 - access(("N4"=6 OR "N4"=8 OR "N4"=19 OR "N4"=28)) 


多 种 表达 式 的 动态 条 件 : 
Oracle 数 据 库 不 支持 IN 条 件 中 有 超过 1000 个 表达 式 。 即 使 可 以 使 用 多 个 分 隔 谓词 来 变通 ， 但 从 
性 能 的 角度 考虑 ， 最 好 设置 限制 。 因 此， 既 不 应 该 在 IN 条 件 中 使 用 过 多 的 表达 式 ， 也 不 应 该 使 用 分 
隔 谓词 来 绕 过 1000 个 表达 式 的 限制 。 实 际 上 ， 应 该 尽 可 能 避免 长 列表 的 表达 式 会 带 来 的 性 能 问题 
相反 ， 应 该 使 用 以 下 技巧 之 
口 基于 读 取 ( 临时 ) 表 的 子 查询 使 用 IN 条 件 
口 使 用 基于 对 象 类 型 和 为 每 个 元 素 返回 单行 的 谈 套 表 ， 作 为 输入 的 管道 表 函 数 的 子 查询 使 用 IN 
条 件 
口 使 用 MEMBER 条 件 来 测试 一 个 元 素 是 否 是 基于 对 象 类 型 的 嵌 套 表 成 员 
Dynamic in_conditions.sql 脚 本 为 每 一 项 技巧 提供 了 例子 。 
i 2 EE 
10. LIKE 条 件 
数据 引擎 能 够 使 用 LIKE 条 件 作为 访问 谓词 ， 但 仅 基于 第 一 个 通配符 前 的 字符 串 。 结 果 ， es 
式 并 不 是 从 通配符 开始 的 (下划线 和 百 分 号 )，LIKE 条 件 与 范围 条 件 以 相同 的 方式 执行 。 此 外 ， 
避免 全 表 扫 描 或 非 全 索引 扫描 。 下 面 举例 说 明 。 前 两 个 查询 分 别 取 回 了 ci 列 和 c2 列 所 有 以 字 ee 
的 行 。 因 此 ， 会 执行 范围 扫描 。 第 三 个 和 第 四 个 查询 分 别 取 回 了 c1 列 和 c2 列 所 有 在 任意 位 置 包含 字母 
A 的 行 。 因 此 会 执行 全 索引 扫描 : 
SELECT /*+ index(t i c1) */ * FROM t WHERE c1 LIKE 'A%' 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 4 ‘91 
| 1| TABLE ACCESS BY INDEX ROWID| T | 1| 119 | 
|* 2 | INDEX RANGE SCAN |Idc | 1| 119 | 
2 - access("C1" LIKE 'A%') 
filter("C1" LIKE 'A%') 
SELECT /*+ index(t i c2) */ * FROM t WHERE C2 LIKE 'A%' 
| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1| 108 | 
| 1| TABLE ACCESS BY INDEX ROWID |T | 1| 108 | 
| 2 | BITMAP CONVERSION TO ROWIDS| | 1 | 108 | 
|* 3| BITMAP INDEX RANGE SCAN | IC2 | | 108 | 
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3 - access("C2" LIKE 'A%') 
filter(("C2" LIKE 'A%' AND "C2" LIKE 'A%')) 


SELECT /*+ index(t i c1) */ * FROM t WHERE c1 LIKE '%A%' 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT 1| 92 | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 1 | 1921 | 
I* 2 | INDEX FULL SCAN | ic | 1 | 6 并 | 


2 - filter(("C1" LIKE '%A%' AND "C1" IS NOT NULL)) 


SELECT /*+ index(t i c2) */ * FROM t WHERE c2 LIKE '%A%' 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | 1| 1846 | 
| 1| TABLE ACCESS BY INDEX ROWID | T -| 1 | 1846 | 
| 2| BITMAP CONVERSION TO ROWIDS| t 1 | 1846 | 
l* 3| BITMAP INDEX FULL SCAN | 工 C2 | 1 | 1846 | 


3 - filter(("C2" LIKE '%A%’' AND "C2" IS NOT NULL)) 


11. 不 等 式 与 IS NOT NULL 条 件 

正如 表 13-3 所 示 ， 基 于 不 等 式 ( !=，<> ) 或 IS NOT NULL 条 件 无 法 使 用 索引 范围 扫描 。 为 了 举例 说 
明 这 种 限制 并 介绍 如 何 优化 这 类 SQL 语句 ， 让 我 们 看 一 个 基于 inequalities.sql 脚 本 的 例子 。Test 表 有 
一 个 分 布 不 均匀 的 列 叫 作 status。 实 际 上 ， 大 部 分 行 的 status 都 设置 为 processed (P)。 示 例如 下 : 


SQL> SELECT status, count(*) 
2 FROM 七 
3 GROUP BY status; 


5 COUNT(*) 

A .| | 

Pp 159981 

人 证 
8 


一 个 应 用 选择 所 有 status 不 是 processed 的 列 。 为 此 ， 它 执行 以 下 查询 : 
SELECT * FROM 七 WHERE status != “P” 


即使 查询 有 很 强 的 选择 性 并 且 status 列 上 有 索引 ， 查 询 优化 器 为 了 读 取 19 行 而 选择 全 表 扫 描 还 是 
导致 了 实在 太 多 的 逻辑 读 (23063 ): 


| Id | Operation | Name | Starts | A-Rows | Buffers 
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| 0 | SELECT STATEMENT | | | 19 | 23063 | 
|* 1 | TABLE ACCESS FULL| T | | 19 | 23063 | 


1 - filter("STATUS"<>'P') 
在 这 样 的 例子 中 ， 不 等 式 条 件 有 很 强 的 选择 性 ， 不 过 可 以 利用 索引 。 可 以 使 用 以 下 三 种 技巧 。 
第 一 ， 如 果 不 等 式 条 件 可 以 写 进 IN 条 件 中 ,那么 就 可 以 使 用 索引 范围 扫描 。 这 仅 当 已 知 选择 值 的 
数量 并 且 数 量 有 限时 使 用 。 下 面 的 查询 举例 说 明 : 


SELECT * FROM 七 WHERE status IN ('A','R','X') 


| Id | Operation | Name | Starts | A-Rows | Buffers 

| 0 | SELECT STATEMENT | | 全 |] 19 | 13 | 
| 1 | INLIST ITERATOR | | 1 | 19 | 13 | 
| 2| TABLE ACCESS BY INDEX ROWID| T | 3 | 19 | 13 | 
|* 3 | INDEX RANGE SCAN | ISTATUS | | 19 | 7 | 


3 - access(("STATUS"="A* DR "STATUS"="R" OR “STATUS”="X")) 

第 二 ， 如 果 上 一 条 技巧 由 于 值 未 知 或 值 的 数量 指定 过 高 而 不 能 使 用 ,那么 可 以 分 成 两 个 范围 谓词 
重 写 不 等 式 ， 结 果 就 可 以 对 它们 每 个 执行 一 次 索引 范围 扫描 。 可 以 考虑 利用 or 扩展 查询 转换 ( 请 参考 
第 6 章 关 于 它 的 信息 ) 查询 重 写 后 会 像 下 面 这 样 : 

SELECT * FROM 七 WHERE status < 'P' OR status > 'P' 


Id Operation Name | Starts | A-Rows | Buffers 
0 | SELECT STATEMENT | 二 | 19 | 4 | 
| 1 | CONCATENATION | 1 | 19 | 12 | 
TABLE ACCESS BY INDEX ROWID| T | 年 | 史 | 5 | 
* 3 INDEX RANGE SCAN I_STATUS | 1 | | 3 | 
4 TABLE ACCESS BY INDEX ROWID| T 1 | 12 | | 
* 5 INDEX RANGE SCAN LI STATUS | 1 | 12 | 3 | 


3 - access("STATUS"<'P’') 
5 - access("STATUS">'P') 
filter(LNNVL("STATUS"<'P')) 
万 一 or 扩展 并 没有 自动 生效 ， 可 以 手动 重 写 查询 来 确保 组 件 查询 可 以 利用 索引 范围 扫描 并 且 将 逻 
辑 读 减 至 最 小 : 
SELECT * FROM t WHERE status < 'P" 


UNION ALL 
SELECT * FROM t WHERE status > 'P" 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
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| 0 | SELECT STATEMENT | | 1 | 9 | 12 | 
| | UNION-ALL | | 1 | | 42 | 
| 2| TABLE ACCESS BY INDEX ROWID| T | 4 | 7 | - 调 
|* 3 | INDEX RANGE SCAN | ISTATUS | 1 | Yi 3 

| 4 | TABLE ACCESS BY INDEX ROWID| T | 1 | 2 | 7 | 
上 t 有 | INDEX RANGE SCAN | I STATUS | | | | 


3 - access("STATUS"<'P') 
5 - access("STATUS">'P') 
第 三 个 技巧 基于 索引 全 扫描 。 要 使 用 它 ， 可 以 使 用 index hint 强 制 执行 索引 全 扫描 。 从 性 能 角度 考 
虑 ， 正 如 下 面 的 例子 所 示 ， 这 不 是 最 优 的 办 法 。 对 于 强 选 择 性 的 查询 ， 逮 辑 读 数 (299 ) 和 返回 行 数 
(19 ) 的 比例 太 高 了 : 
SELECT /*+ index(t) */ * FROM t WHERE status != 'P' 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | LE 19 | 299 | 
| 1 | TABLE ACCESS BY INDEX ROWID| T 2 | 1 | 19 | 299 | 
|* 2 | INDEX FULL SCAN | LSTATUS | 1 | 19 | 293 


2 - filter("STATUS"<S'p') 

要 想 以 最 优 的 方式 执行 索引 全 扫描 ， 索 引 的 大 小 应 该 尽 可 能 小 。 要 达到 这 个 目的 ， 有 两 个 技巧 可 
以 使 用 。 第 一 个 的 目的 是 定义 函数 索引 ( 稍 后 , “函数 索引 ”部 分 会 提供 这 些 索 引 的 附加 信息 ) 来 避 
免 索 引 热 门 值 。 要 使 用 这 个 技巧 ， 索 引 和 使 用 索引 的 SQL 语 句 都 需要 修改 。 

口 创建 函数 索引 来 排除 热门 值 ( 对 于 更 复杂 的 条 件 ， 也 可 以 使 用 CASE 表 达 式 或 decode 函 数 ): 

CREATE INDEX i status ON t (nullif(status, 'P')) 

口 修改 查询 的 谓词 来 使 用 索引 : 

SELECT * FROM 七 WHERE nullif(status, 'P') IS NOT NULL 


| Id | Operation | Name | Starts | A-Rows | Buffers 
| 0 | SELECT STATEMENT | | 4 | 19 | -| 
| 1| TABLE ACCESS BY INDEX ROWID| T | a | 19 | 9 | 
|* 2 | INDEX FULL SCAN | I_STATUS | 1 | 19 | 3 


2 - filter("T"."SYS NCO0004$" IS NOT NULL) 
第 二 个 技巧 的 目的 是 使 用 NULL 值 替换 最 热门 的 值 ， 从 而 避免 大 部 分 行 被 索引 引用 。 但 是 请 注意 ， 
这 个 技巧 只 对 B 树 索引 有 效 。 要 实现 它 ， 需 要 执行 以 下 步骤。 
口 使 用 NULL 替 换 最 热门 的 值 : 


UPDATE 七 SET status = NULL WHERE status = 'P'" 
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口 重建 索引 以 将 其 大 小 缩 至 最 小 : 
ALTER INDEX i status REBUILD 
口 使 用 IS NOT NULL 替 换 不 等 值 : 
SELECT * FROM t WHERE status IS NOT NULL 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | | 19 | 10 | 
| 1| TABLE ACCESS BY INDEX ROWID| T | :| 19 | 10 | 
|* 2 | INDEX FULL SCAN | I_STATUS | 到 19 | 3 


2 - filter("STATUS" IS NOT NULL) 


总 之 ， 正 如 上 一 例子 所 示 ， 可 以 使 用 不 等 式 或 IS NOT NULL 条 件 来 高 效 执行 SQL 语句 。 但 是 ， 需 要 
特别 处 理 。 

12. Min/Max 遂 数 

要 高 效 执行 包含 min 或 max 函 数 的 查询 ， 可 以 使 用 B 树 索引 执行 两 个 具体 操作 。 第 一 个 ，INDEX FULL 
SCAN(MIN/MAX) ， 当 查询 没有 指定 范围 条 件 时 使 用 。 然而 , 不 要 管 它 的 名 称 , 它 执 行 的 不 是 全 索引 扫描 
它 只 是 简单 地 获得 索引 键 最 左边 或 最 右边 的 值 : 


SELECT /*+ index(t t pk) */ min(id) FROM t 


| Id | Operation | Name | Staits | A-Rows | 
| 0 | SELECT STATEMENT | | 1 | 1 | 
| 1 | SORT AGGREGATE | | | | 
| 2| INDEX FULL SCAN (MIN/MAX)| T PK | "| | 


第 二 个 是 INDEX RANGE SCAN(MIN/MAX) ， 当 查询 在 使 用 函数 的 列 上 指定 条 件 时 使 用 : 
SELECT /*+ index(t t pk) */ min(id) FROM t WHERE id > 42 


| Id | Operation | Name | Starts | A-Rows | 


0 | SELECT STATEMENT | 
1 | SORT AGGREGATE | 
2 | FIRST ROW | 
3 | INDEX RANGE SCAN (MIN/MAX)| T_PK 


3 - access("ID">42) 
不 幸 的 是 ， 在 同一 个 查询 中 同时 使 用 这 两 个 函数 (min 和 max ) 时 ， 无 法 使 用 这 个 优化 技巧 。 在 这 
种 情况 下 ， 会 执行 索引 全 扫描 。 下 面 的 查询 举例 说 明 : 
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SELECT /*+ index(t t pk) */ min(id), max(id) FROM t 
Plan hash value: 56794325 


| Id | Operation | Name | Starts | A-Rows | 
| 0 | SELECT STATEMENT | | | 1 

| 1| SORT AGGREGATE | | 1 | 1 | 
| 2| INDEX FULL SCAN| T_PK | 1 | 10000 | 


对 于 位 图 索引 来 说 ， 并 没有 特别 的 操作 用 来 执行 nin 和 max 函 数 。 会 使 用 与 等 式 条 件 和 范围 条 件 相 
同 的 操作 。 


13. 函数 索引 

每 次 索引 列 作为 参数 传递 给 函数 时 ， 或 涉及 表达 式 时 ，SQL 引 擎 就 无 法 使 用 建立 在 对 应 列 上 的 索 
引 来 做 索引 范围 扫描 。 因 此 ， 其 中 要 遵守 的 一 个 基本 原则 就 是 绝 不 修改 WHERE 子 句 中 的 索引 列 返回 值 。 
例如 ， 如 果 在 ci 列 上 存在 索引 ， 像 opper(c1) = 'SELDON' 的 限制 就 无 法 通过 建立 在 c1 列 上 的 索引 高 效 
使 用 。 这 应 该 很 明显 ， 因 为 你 仅 可 以 搜索 存储 在 索引 中 的 值 ， 而 不 是 别 的 东西 。 下 面 的 例子 ， 与 本 市 
的 其 他 例子 一 样 ， 引 用 自 fbi.sql 脚 本 : 


SOL> CREATE INDEX i cl ON t (c1); 


SQL> SELECT * FROM t WHERE upper(c1) = 'SELDON'; 


| Id | Operation | Name | E-Rows | A-Rows | 
| 0 | SELECT STATEMENT | | | 4 | 
|* 1 | TABLE ACCESS FULL| T | 100 | 4 | 


1 - filter(UPPER("C1")="SELDON') 
基本 原则 的 一 个 例外 是 当 约 束 确保 索引 包含 了 必要 的 信息 时 。 举 例 说明 这 种 情况 ,在 ci 列 上 有 两 
个 约束 为 查询 优化 器 提供 信息 : 
SOL> ALTER TABLE t MODIFY (c1 NOT NULL); 
SQL> ALTER TABLE t ADD CONSTRAINT t c1 upper CHECK (c1 = upper(c1)); 


SOL> SELECT * FROM t WHERE upper(c1) = 'SELDON'; 


0 | SELECT STATEMENT | | 4 | 
1 | TABLE ACCESS BY INDEX ROWID| T | 100 | 4 | 
2 | INDEX RANGE SCAN | Ici| 4 | 
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2 - access("C1"="'SELDON') 
filter(UPPER("C1")="'SELDON') 


显然 ， 如 果 限 制导 致 强 选择 性 ， 你 会 想 要 利用 索引 。 为 了 这 个 目的 ， 如 果 不 能 修改 WHERE 子 句 或 指 
定 约 束 ， 可 以 创建 卫 数 索引 。 简单 地 说 ， 这 是 创建 在 函数 返回 值 或 表达 式 结果 上 的 索引 。 下 面 是 例子 : 
SQL> CREATE INDEX i c1 upper ON t (upper(c1)); 


SQL> SELECT * FROM t WHERE upper(c1) = 'SELDON'; 


| 0 | SELECT STATEMENT | | 
| 1| TABLE ACCESS BY INDEX ROWID| T 4 
|* 2 | INDEX RANGE SCAN | I_C1 UPPER | 4 


2 - access(UPPER("C1")="SELDON') 


警告 ”函数 索引 是 使 用 文字 作为 参数 的 函数 , 将 初始 化 套数 cursor sharing 设 置 为 force 或 similar 时 ， 
查询 优化 器 不 会 选择 它 。 这 是 因为 文字 被 绑 定 变量 替代 了 -fbi cs.sql 脚 本 展示 了 这 样 的 案例 


正如 第 8 章 中 的 “扩展 的 执行 计划 ”部 分 介绍 的 那样 ， 函 数 使 用 和 WwHERE 子 句 中 表达 式 的 男 一 个 相 
关 问 题 是 ， 查 询 优 化 器 错 估 由 行 的 源 操作 应 用 它们 而 产生 的 结果 集 基 数 。 本 节 中 的 例子 ( 请 注意 执行 
计划 中 的 E-Rows 和 A-Rows ) 使 用 函数 索引 来 举例 说 明 ， 查 询 优化 器 也 可 以 提高 它 作出 的 估量 。 并 且 这 
种 提高 可 以 与 函数 索引 是 否 用 来 访问 数据 无 关 。 可 以 有 更 准确 的 估量 ， 因 为 每 个 函数 索引 都 会 将 一 个 
隐藏 列 添加 到 它 创 建 的 表 上 。 由 于 列 的 统计 信息 和 直方 图 也 会 为 隐藏 列 收集 ， 因 此 查询 优化 器 获取 到 
的 附加 信息 需要 函数 索引 才 可 以 使 用 。 重 点 也 需要 指出 ,在 表 级 别 上 对 于 新 的 隐藏 对 象 在 孔 数 索引 创 
建 时 不 会 收集 统计 信息 。 只 会 自动 收集 索引 统计 信息 。 因 此 , 在 创建 完 新 的 函数 索引 时 ， 不 要 忘记 收 
集 表 级 别 的 对 象 统计 信息 。 

函数 索引 也 可 以 创建 PL/SQL 的 用 户 自 定义 函数 。 唯 一 的 要 求 是 函数 必须 定义 为 DETERMINISTIC 


警告 基于 用 户 自 定 义 函 数 的 函数 索引 ， 当 它们 依赖 的 PL/SQL 代 码 改 变 时 并 不 会 无 效 或 标记 为 不 可 
用 。 当然， 可 能 会 导致 错误 的 结果 。 如 果 改 变 了 这 样 的 函数 代码 ， 应 该 立刻 重建 依赖 的 索引 
fbi_udf.sql 脚 本 中 有 这 个 操作 的 例子 。 


从 11.1 版 本 开始 ， 为 了 避免 索引 或 SQL 语 句 中 重复 的 函数 或 表达 式 ， 可 以 基于 函数 或 表达 式 创建 
虚拟 列 。 这 样 ， 因 可 以 直接 在 虚拟 列 上 创建 ， 代 码 对 定义 来 说 就 可 以 是 透明 的 了 。 下 面 的 例子 展示 如 
何 添加 、 创 建 索 引 以 及 使 用 虚拟 列 将 upper 函 数 应 用 到 c1 列 上 : 

SQL> ALTER TABLE 七 ADD (c1_upper AS (upper(c1))); 


SQL> CREATE INDEX i c1 upper ON t (c1 upper); 
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SQL> SELECT * FROM t WHERE c1 upper = “SELDON ; 


0 | SELECT STATEMENT | | 
1 | TABLE ACCESS BY INDEX ROWID| T | 
2 | INDEX RANGE SCAN | I C1 UPPER | 


2 - access("C1 UPPER"="'SELDON') 


本 节 中 的 例子 虽然 都 是 基于 B 树 索引 ， 但 也 都 支持 函数 位 图 索引 。 


14. 语言 索引 

默认 情况 下 ， 数 据 库 引 擎 会 执行 二 进 制 比较 (binary comparision ) 来 对 比 字符 串 。 字 符 可 以 通过 
其 二 进 制 值 来 进行 对 比 。 因 此 ， 仅 在 每 个 对 应 的 数字 代码 匹配 时 ， 才 会 认为 两 个 字符 串 是 相等 的 。 

数据 库 引 擎 也 能 够 执行 语言 对 比 (linguistic comparision )。 使 用 这 些 对 比 ， 每 个 字符 的 数字 代码 
并 不 需要 完全 相同 , 例如 , 可 以 设置 数据 库 引 擎 识别 小 写 和 大 写字 符 是 相同 的 , 或 者 没有 重音 的 字符 。 
要 管理 SQL 操作 的 行为 ， 可 以 使 用 初始 化 参数 nls_comp。 可 以 将 其 设置 为 以 下 值 之 一 。 

口 binary: 使 用 二 进 制 对 比 。 这 是 默认 值 。 

口 linguistic: 使 用 语言 对 比 。 初 始 化 参数 ms_sort 指 定 应 用 于 对 比 的 语言 排列 顺序 (还 有 规则 )。 

对 应 版 本 可 以 接受 的 值 可 以 通过 以 下 查询 查 到 : 
SELECT value FROM v$nls valid values WHERE parameter = “SORT 

口 ansi: 该 值 只 对 向 下 兼容 有 效 。 会 使 用 linguistic 来 蔡 代 。 

在 实例 和 会 话 级 别 上 可 以 设置 动态 初始 化 参数 nls comp 和 mls_sort。 在 会 话 级 别 上 ， 可 以 通过 
ALTER SESSION 语句 设置 它们 ; 也 可 以 在 操作 系统 级 别 上 ， 在 客户 端 ( 例如 ， 在 Microsoft Windows 注 册 
表 中 ) 定义 它们 。 请 注意 在 客户 端 进行 设置 属于 正常 情况 ,不 是 例外 。 因 此 ， 客 户 端 设 置 覆 盖 服 务 器 
端 设置 是 很 常见 的 。 

举 个 例子 ， 假 设 一 张 表 保存 以 下 数据 ( 表 和 Test 查 询 可 以 在 linguistic index.sql 脚 本 中 找到 ): 


SQOL> SELECT c1 FROM t; 
€l 


默认 情况 下 ,执行 二 进 制 对 比 。 要 使 用 语言 对 比 ,需要 将 初始 化 参数 nls_comp 设 置 为 linguistic， 
并 且 必 须 通 过 初始 化 参数 nls_sort 指 定语 言 排列 顺序 ( 还 有 规则 )。 下 面 的 例子 使 用 generic_m，ISO 标 
准 的 拉丁 字符 : 

SOL> ALTER SESSION SET nls comp = linguistic; 


SOL> ALTER SESSION SET nls sort = generic m; 
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SQL> SELECT c1 FROM 七 WHERE c1 = "LEON'; 


正如 预料 的 那样 ， 使 用 上 面 的 设置 没有 什么 特别 的 会 发 生 。 这 个 特性 由 两 个 扩展 generic_m 提 供 。 
第 一 个 是 generic_m_ci。 正 如 下 面 的 查询 展示 的 那样 ， 使 用 它 进 行 对 比 不 区 分 大 小 写 : 
SQL> ALTER SESSION SET nls sort = generic m ci; 


SQL> SELECT c1 FROM t WHERE c1 = "LEON ; 


第 二 个 是 generic_m_ai。 正 如 下 面 的 查询 展示 的 那样 ， 使 用 它 进行 对 比 区 分 大 小 写 和 重音 : 
SQL> ALTER SESSION SET nls_sort = generic m ai; 


SQL> SELECT c1 FROM 七 WHERE EL = "LEON'; 


从 功能 的 角度 考虑 ， 这 个 功能 很 好 。 通 过 设置 两 个 初始 化 参数 ， 可 以 控制 SQL 操作 的 行为 。 让 我 
们 来 检查 一 下 ， 将 初始 化 参数 mls_comp 设 置 为 linguistic 时 ， 执 行 计 划 是 和 否 会 发 生 改 变 ; 
SQL> CREATE INDEX i c1 ON t (cd); 


SQL> ALTER SESSION SET nls sort = generic m ai; 
SQL> ALTER SESSION SET nls comp = binary; 


SQL> SELECT /*+ index(t) */ * FROM t WHERE c1 = "LEON ; 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
| 1 | TABLE ACCESS BY INDEX ROWID| T | 
|* 2 | INDEX RANGE SCAN | EE | 


2 - access("C1"='LEON') 
SQL> ALTER SESSION SET nls comp = linguistic; 


SQL> SELECT /*+ index(t) */ * FROM t WHERE c1 = “LEON ; 
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| 0 | SELECT STATEMENT | | 
|* 1 | TABLE ACCESS FULL| T | 


1 - filter(NLSSORT("C1", 'nls_sort="'GENERIC M AI''')=HEXTORAW('022601FE02380232') ) 


显然 ,将 初始 化 参数 nls_comp 设 置 为 linguistic 时 ， 就 不 会 再 使 用 索引 。 输 出 的 最 后 一 行 表 明了 
原因 。 因 为 函数 nlssort 是 隐 式 应 用 给 索引 列 c1， 所 以 不 会 在 索引 中 进行 查找 。 因 此 ， 出 于 这 个 目的 ， 
函数 索引 需要 避免 全 表 扫 描 。 重点 需要 认识 到 , 索引 的 定义 必须 包含 与 初始 化 参数 mls_sort 相 同 的 值 。 


因此 ， 如 果 使 用 多 种 语言 ， 就 需要 创建 多 个 索引 : 
SQL> CREATE INDEX i c1 linguistic ON t (nlssort(c1,'nls sort=generic m ai')); 


SQL> SELECT /*+ index(t) */ * FROM t WHERE c1 = “LEON ; 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | ' | 
| 1| TABLE ACCESS BY INDEX ROWID| T 

名 朗 | INDEX RANGE SCAN | I C1 LINGUISTIC | 


2 - access(NLSSORT("C1", 'nls sort="'GENERIC M AI''')=HEXTORAW('022601FE02380232') ) 


在 10.2 版 本 中 ,为 了 应 用 LIKE 操 作 还 有 男 外 一 个 限制 , 数据 库 引 擎 不 能 使 用 语言 索引 。 换 句 话 说 ， 


全 索引 扫描 或 全 表 扫 描 无 法 避免 。 该 限制 在 11.1 版 本 之 后 不 再 存在 。 
即使 本 节 的 例子 都 是 基于 B 树 索引 ， 但 也 同样 支持 语言 索引 。 
下 面 的 例子 展示 了 语言 索引 也 可 以 用 来 避免 ORDER BY 操作 : 
SQL> SELECT /*+ index(t) */ * FROM t WHERE c1 BETNEEN 'L' AND 'M' ORDER BY c1; 


0 | SELECT STATEMENT | | 
1 | TABLE ACCESS BY INDEX ROWID| T | 
2 | INDEX RANGE SCAN | I C1 LINGUISTIC | 


2 - access(NLSSORT("C1", 'nls sort="'GENERIC M AI''')>=HEXTORAW('0226') AND NLSSORT( 
"C1", 'Nls sort="'GENERIC M AI''')<=HEXTORAW('0230') ) 


总 之 ， 语 言 对 比 是 一 个 强大 的 特性 ， 而 它 对 SQL 语句 来 说 是 透明 的 。 然 而 ， 仅 在 一 组 适合 的 索引 
存在 时 ， 数 据 库 引 擎 才 可 以 高 效 使 用 它们 。 因 为 在 客户 端 级 别 的 设置 会 影响 索引 的 使 用 ， 因 此 必须 说 


慎 使 用 。 
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15. 复合 索引 

到 目前 为 止 ， 除 了 一 个 例外 ,我 讨论 了 索引 键 只 包含 单独 一 列 的 索引 。 然 而 ， 索 引 键 可 以 包含 
多 列 ( 对 于 B 树 索引 来 说 限制 是 32, 位 图 索引 是 30 )。 使 用 多 列 的 索引 叫 作 复合 索引 ( composite index ， 
有 时 也 叫 组 合 索 引 ，concatenated index 或 多 列 索引 ，mnulticolumn index )。 在 这 一 点 上 ，B 树 索引 与 位 
图 索引 完全 不 同 。 所 以 我 会 分 开 讨 论 它们 。 请 注意 ， 本 节 中 的 所 有 例子 都 基于 composite index.sql 
脚本 。 


@ B 树 索引 

复合 索引 的 目的 有 两 个 。 第 一 ,它们 可 以 用 来 实现 由 多 列 组 成 的 主键 或 唯一 索引 约束 。 第 二 , 它 
们 能 够 应 用 由 多 个 SQL 条 件 使 用 AND 组 成 的 谓词 。 请 注意 ， 当 多 个 SQL 条 件 使 用 OR 来 组 合 时 ,无 法 高 效 
使 用 复合 索引 ! 

自然 地 ， 重 点 是 讨论 如 何 使 用 复合 索引 来 应 用 限制 。 下 面 查询 的 用 途 就 是 这 个 : 

SELECT * FROM 七 WHERE n1 = 6 AND n2 = 42 AND n3 = 11 

让 我 们 来 看 看 当 使 用 单列 索引 时 会 发 生 什么 。 使 用 在 ni 列 上 创建 的 索引 ， 索 引 扫 描 返 回 了 527 个 
rowid。 因 为 索引 值 保存 了 ni 列 相 关 的 数据 ， 只 有 操作 2 的 nl = 6 谓词 可 以 通过 索引 访问 。 其 他 两 个 谓 
词 被 操作 1 应 用 为 过 滤器 。 由 于 操作 2 返回 了 很 多 rowid， 执 行 计 划一 共生 成 了 327 个 逻辑 读 。 当 取 回 单 
行 时 ， 这 是 无 法 接受 的 : 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 秋 中 1 | 327 | 
|* 414 | TABLE ACCESS BY INDEX ROWID| T | rd | 中 327 | 
|* 2 | INDEX RANGE SCAN [I NL | | 527 | 4 | 


1 - filter(("N2"=42 AND "N3"=11)) 
2 - access("N1"=6) 
使 用 在 n2 列 上 创建 的 索引 ,情况 基本 与 上 个 例子 一 致 。 唯 一 改进 的 是 ,索引 扫描 返回 了 更 少 的 rowid 
( 89 )。 因 此 一 共 执 行 的 逻辑 读数 ( 85 ) 也 少 得 多 : 


| Id | 0peration | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 1 | 1 | 85 | 
|* 1 | TABLE ACCESS BY INDEX ROWID| T | 生 1 | 85 | 
|* 2 | INDEX RANGE SCAN | IN2 | 中 89 | 4 | 


1 - filter(("N3"=11 AND "N1"=6)) 
2 - access("N2"=42) 
使 用 在 n3 列 上 创建 的 索引 , 情况 仍然 与 前 两 个 很 相似 。 实际 上 , 索引 扫描 返回 了 许多 rowid ( 164 )。 
一 共 的 逻辑 读数 ( 141 ) 仍然 太 高 : 


| Id | 0peration | Name | Starts | A-Rows | Buffers | 


13.3， 强 选择 性 的 SQL 语句 455 


| 0 | SELECT STATEMENT | 1 | 1 | 141 | 
|* 1 | TABLE ACCESS BY INDEX ROWID| T | 1 | 11 141 | 
|* 2 | INDEX RANGE SCAN | IN3 | 1| 164 | 4 


1 - filter(("N2"=42 AND "N1"=6)) 
2 - access("N3"=11) 
总 之 , 这 三 个 索引 没有 一 个 可 以 高 效 地 应 用 谓词 。 这 三 个 限制 的 选择 性 太 高 。 观 察 到 的 与 存储 在 
数据 字典 中 的 对 象 统计 信息 一 致 。 实 际 上 ， 每 一 列 非 重复 值 的 数量 很 低 ， 请 查看 以 下 查询 演示 : 
SOL> SELECT column name, num distinct 


2 FROM user tab columns 
3 WHERE table name = 'T'" AND column name IN ('ID'’, 'N1', 'N2', 'N3'); 


COLUMN_NAME NUM DISTINCT 


ID 10000 
N1 18 
N2 2 
N3 60 


在 这 样 的 情况 下 ， 在 多 个 列 上 创建 的 单个 索引 应 用 各 种 条 件 会 更 高 效 。 例如， 下 面 的 执行 计划 展 
示 了 如 果 在 三 列 上 创建 一 个 复合 索引 时 ， 会 发 生 什 么 。 重 点 需要 知道 使 用 这 个 索引 ， 逻 辑 读数 (4 ) 
会 更 低 ， 因 为 索引 扫描 仅 返 回 了 满足 整个 WHERE 子 句 的 行 ( 本 例 中 仅 返 回 一 行 ): 


| Id | Operation | Name | Starts | A-Rows | Buffers 
| 0 | SELECT STATEMENT | | | 于 | 4 | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 1 | 1 | 4 | 
|* 2 | INDEX RANGE SCAN | IN123 | 1 | 1 | 3 


2 - access("N1"=6 AND "N2"=42 AND "N3"=11) 
此 时 ,重点 需要 认 清 ， 即 使 引用 自 wHERE 子 句 中 的 列 不 都 是 索引 创建 的 列 ， 数 据 库 引擎 也 能 够 执 
行 索引 范围 扫描 。 基 本 要 求 是 ， 应 该 将 条 件 应 用 到 索引 键 的 引导 列 上 。 例 如 ， 使 用 上 一 例 中 的 1_n123 
索引 ， 列 n2 和 m3 的 条 件 是 可 选 的 。 下 面 的 查询 展示 了 在 n2 列 上 没有 条 件 存在 的 例子 : 
SELECT * FROM t WHERE n1 = 6 AND n3 = 11 


| Id | Operation | Name | Starts | A-Rows | Buffers 

| 0 | SELECT STATEMENT | | | 8 | 

| 1 | TABLE ACCESS BY INDEX ROWID| T | :| 8 | | 
|* 2 | INDEX RANGE SCAN | I N123 | 1 | 8 | 4 | 


2 - access("N1"=6 AND "N3"=11) 
filter( "NS "=14) 
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上 一 个 执行 计划 需要 知道 ， 即 使 na = 11 的 谓词 出 现在 访问 谓词 里 , 但 所 有 满足 n1 = 6 的 谓词 索引 
键 都 需要 访问 到 。 一 方面 ， 这 个 方法 是 次 优 的 ， 因 为 访问 了 索引 不 需要 的 部 分 。 另 一 方面 ,正如 上 一 
个 例子 展示 的 那样 ， 在 索引 扫描 期 间 应 用 n3 = 11 的 谓词 ， 作 为 过 滤器 要 比 在 访问 表 时 应 用 好 得 多 。 无 
论 如 何 ， 为 了 获得 最 佳 性 能 ， 谓 词 应 该 应 用 在 索引 的 引导 列 上 

当 没 有 条 件 在 索引 键 的 引导 列 上 时 ， 也 有 索引 可 以 被 ( 高效 ) 使 用 的 案例 。 这 样 的 操作 叫 作 索引 
跳跃 扫描 ( index skip scan )。 然 而 ， 只 有 在 引导 列 的 非 重复 值 数量 非常 小 时 才 可 以 使 用 ， 因 为 会 对 引 
导 列 的 每 个 值 单独 进行 索引 范围 扫描 。 下 面 的 查询 展示 了 这 样 的 例子 。 请 注意 index_ss hint 和 INDEX 
SKIP SCAN 操 作 : 

SELECT /*+ index ss(t i n123) */ * FROM t WHERE n2 = 42 AND n3 = 11 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | 1 | 2 | 33 | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 炎 | 要 :| 33 | 
lf 2 | INDEX SKIP SCAN | 工 N123 | 史 | 2 | 31 | 


2 - access("N2"=42 AND "N3"=11) 
filter(("N2"=42 AND "N3"=11)) 


因为 “常规 ”索引 扫描 (使 用 INDEX SKIP SCAN DESCENDING 操 作 ) 支持 降序 索引 跳跃 扫描 ， 所 以 可 
以 使 用 两 个 hint index_ss_asc 和 index_ss_desc 来 控制 扫描 的 顺序 。 

说 到 复合 索引 ， 我 觉得 有 必要 提 到 在 处 理 它们 时 我 遇 到 的 最 常见 错误 ， 也 是 最 常 被 问 到 的 问题 。 
错误 与 过 度 索 引 化 (overindexation ) 有 关 。 总 是 佟 错误 地 认为 ， 仅 当 所 有 组 成 索引 键 的 列 在 NHERE 子 
句 中 时 ,数据 库 引 擎 才能 使 用 索引 。 在 已 经 看 到 的 数 个 例子 中 ， 其 实 并 不 是 这 么 回 事 。 这 个 误解 通常 
会 导致 在 同一 张 表 上 创建 使 用 相同 引导 列 的 数 个 索引 ， 比 如 ， 一 个 索引 使 用 n1、n2 和 n3 列 ， 而 另 一 个 
索引 使 用 n1 和 nm3 列 。 第 二 种 通常 是 不 需要 的 。 请 注意 这 个 多 余 的 索引 会 是 个 问题 ， 因 为 它们 不 仅 会 降 
低 SQL 语 句 修改 索引 数据 的 速度 ， 同 时 也 浪费 了 不 必要 的 空间 。 

最 常 被 问 到 的 问题 是 : 如 何 选 择 列 的 顺序 。 比 如 ， 如 果 索 引 键 由 n1、n2 和 n3 列 组 成 ， 哪 种 顺序 最 
好 ? 当 所 有 索引 列 都 在 WHERE 子 句 中 时 ， 索 引 的 效率 与 索引 中 列 的 顺序 无 关 。 因 此 ， 最 好 的 顺序 就 是 ， 
当 并 非 所 有 索引 列 都 在 WHERE 子 句 中 时 ， 可 以 尽 最 大 可 能 频繁 地 使 用 索引 。 换 句 话 说， 应 该 使 索引 可 
以 供 最 大 数量 的 SQL 语句 使 用 。 要 确保 这 种 情况 ， 列 需要 根据 它们 使 用 的 频率 来 排序 。 尤 其 应 该 将 引 
导 列 指定 为 WHERE 子 句 中 使 用 更 频繁 的 那个 〈 当然 ， 理 想 状 态 )。 每 当 多 列 使 用 相同 频率 时 ， 有 以 下 两 
个 对 立 的 方法 可 供 选 择 。 

口 引导 列 应 该 是 预期 提供 最 好 选择 性 的 列 。 如 果 只 使 用 等 式 ， 就 应 该 用 非 重复 值 数 最 高 的 那 一 
列 。 如 果 使 用 范围 条 件 ， 就 与 非 重复 值 数 无 关 了 。 比 如 ， 想 象 一 下 时 间 戳 的 案例 : 很 可 能 非 
重复 值 数 会 很 高 。 但 是 因为 时 间 戳 频繁 用 于 范围 谓词 中 ， 重 要 的 是 真实 选择 性 而 不 是 非 重复 
值 数 。 如 果 限 制 仅 应 用 于 特定 的 列 , 使 用 可 以 提供 强 选 择 性 的 引导 列 对 以 后 的 SQL 语句 会 很 有 
帮助 。 换 句 话 说， 最 大 可 能 地 使 查询 优化 器 能 够 选择 索引 。 

口 引导 列 应 该 是 非 重复 值 数 最 低 的 那 列 。 这 对 提高 索引 压缩 比 很 有 帮助 。 
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索引 压缩 

在 B 树 索引 和 位 图 索引 之 间 有 一 个 很 重要 的 不 同 ， 就 是 使 用 压缩 技术 存储 在 索引 叶 块 中 的 键 
位 图 索引 总 是 使 用 压缩 ， 而 B 树 索引 只 在 需要 的 时 候 才 会 使 用 压缩 

在 一 个 未 压缩 的 B 树 索引 中 ， 每 个 键 都 是 完整 存储 的 。 换 和 句 话说 ， 如 果 多 个 键 有 相同 的 值 ， 会 
分 别 存储 每 个 键 值 。 因 此 ， 在 未 压缩 的 索引 中 ， 在 同一 个 叶 块 上 通常 会 存储 很 多 相同 的 值 。 为 了 禁 
止 这 种 重复 的 发 生 ， 可 以 在 ( 重 ) 建 索引 时 使 用 COMPRESS 参 数 来 压缩 索引 键 ， 并 且 可 选择 需要 压缩 
的 列 数 。 例 如 , i_n123 索 引 由 三 列 组 成 : n1、n2 和 na, 使 用 COMPRESS 1, 指定 仅 压缩 nh1 列 ; 使 用 COMPRESS 
2， 指 定 压 缩 n1 和 n2 列 ; 而 使 用 COMPRESS 3， 指 定 压缩 全 部 三 列 。 当 不 指定 压缩 的 列 数 时 ， 非 唯一 索 
引 会 压缩 所 有 列 ， 而 唯一 索引 会 压缩 列 数 -1 个 列 

由 于 压缩 是 从 左 向 右 ， 列 应 该 按照 选择 性 从 高 到 低 排 列 来 获得 最 好 的 压缩 比例 。 然 而 ， 只 有 在 
无 法 阻止 查询 优化 器 使 用 索引 时 才 会 重 排 索引 的 列 

压缩 B 树 索引 默认 不 启用 ， 这 是 因为 它 并 不 总 能 减 小 索引 大 小 。 实 际 上 ， 在 某 些 情况 下 ， 使 用 
压缩 或 许 会 使 索引 增 大 ! 因此 ， 应 该 仅 在 真正 有 益 的 时 候 启 用 压缩 。 你 有 两 个 选择 来 查看 给 定 索引 
的 预期 压缩 率 , 第 一 , 可 以 创建 索引 不 使 用 压缩 ,然后 再 压缩 ,接着 对 比 大 小 ,第 二 , 可 以 使 用 ANALYZE 
INDEX 语 名 执行 分 析 来 找 出 最 佳 压缩 的 列 数 和 使 用 最 佳 压缩 能 节省 的 空间 大 小 。 下 面 的 例子 展示 针 
对 i _n123 索 引 的 分 析 。 请 注意 分 析 的 输出 写 入 index_stats 表 中 -。 本 例 中 ,你 可 以 知道 对 两 列 使 用 压 
缩 可 以 节省 17% 的 空间 : 

SOL> ANALYZE INDEX i n123 VALIDATE STRUCTURE; 

SQL> SELECT opt cmpr count, opt cmpr pctsave FROM index stats; 


OPT_CMPR COUNT OPT_ CMPR_PCTSAVE 


下 面 的 SQL 语 名 不仅 展示 了 如 何 对 i n123 索 引 实施 压缩 ， 也 展示 了 如 何 查看 压缩 结果 : 
SQL> SELECT blocks FROM index stats; 
BLOCKS 
SQL> ALTER INDEX i n123 REBUILD COMPRESS 2; 
SQOL> ANALYZE INDEX i n123 VALIDATE STRUCTURE; 
SQL> SELECT blocks FROM index stats; 


BLOCKS 
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从 性 能 的 角度 考虑 ,压缩 索引 的 核心 优势 是 因为 它们 更 小 的 体积 , 不仅 在 执行 索引 范围 扫描 和 
索引 全 扫描 时 逻辑 读 更 少 了 ， 而 且 它 们 也 更 可 能 缓存 在 缓冲 区 缓存 中 。 然 而， 缺点 是 可 能 会 增加 遇 
到 块 争 用 的 可 能 ( 这 个 主题 会 在 第 16 章 介绍 )。 
PR ee RE 
@ 位 图 索引 
复合 位 图 索引 很 少 创建 。 因为 多 个 索引 可 以 高 效 地 合并 来 应 用 限制 。 要 想 知 道 位 图 索引 有 多 强大 ， 
让 我 们 来 看 几 个 查询 。 
第 一 个 查询 利用 AND 合 并 三 个 等 式 条 件 来 使 用 三 个 位 图 索引 。 请 注意 index_combine hint 强 制 该 类 
的 执行 计划 。 第 一 ， 操 作 4 基 于 n5 列 在 该 列 查找 满足 限制 的 行 来 扫描 索引 。 作 为 结果 的 位 图 传 给 了 操 
作 3。 接 着 操作 5 和 6 在 n6 列 和 n4 列 的 索引 上 分 别 执行 同样 的 扫描 。 一 旦 三 个 索引 都 完成 扫描 ， 操 作 3 计 
算 三 组 位 图 的 AND 操 作 。 最 后 ,操作 2 转换 作为 结果 的 位 图 为 rowid 列 ， 接 着 操作 1 使 用 它们 访问 表 : 
SELECT /*+ index combine(t i n4 i n5 i n6) */ * 


FROM 七 
WHERE n4 = 6 AND n5 = 42 AND n6 = 11 


| SELECT STATEMENT | | 
| TABLE ACCESS BY INDEX ROWID | T | 
| BITMAP CONVERSION TO ROWIDS| | 
| BITMAP AND | | 
| BITMAP INDEX SINGLE VALUE| I NS | 
| BITMAP INDEX SINGLE VALUE| I_N6 | 
| BITMAP INDEX SINGLE VALUE| I N4 | 


4 - access("N5"=42) 
5 - access("N6"=11) 
6 - access("N4"=6) 


对 于 第 一 个 查询 ， 有 必要 再 向 你 展示 一 下 使 用 复合 位 图 索引 的 执行 计划 。 正 如 你 所 见 ， 人 逻辑 读数 
并 没有 下 降 很 多 ( 4 代替 7 )。 即 使 它 更 好 ， 但 是 这 样 的 复合 索引 远 不 及 三 个 单列 索引 灵活 。 这 就 是 为 
什么 实际 中 很 少 创建 复合 位 图 索引 的 原因 : 


| Id | Operation | Name | Starts | A-Rows | Buffers 

| 0 | SELECT STATEMENT | | 1 | 1 | 4 | 
| 1| TABLE ACCESS BY INDEX ROWID | T | 1 | di 4 | 
| 2| BITMAP CONVERSION TO ROWIDS| | 1 | -| 3 | 
|* 3| BITMAP INDEX SINGLE VALUE | I_N456 | | 4 | :| 


3 - access("N4"=6 AND "N5"=42 AND "N6"=11) 
第 二 个 查询 与 第 一 个 类 似 。 唯 一 的 不 同 是 OR 替代 了 AND。 注 意 在 执行 计划 中 操作 3 仅 有 的 改变 : 


SELECT /*+ index combine(t i n4 i n5 i n6) */ * 
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FROM t 
WHERE n4 = 6 OR n5 = 42 OR n6 = 11 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | 1| 767| 420 | 
| 1 | TABLE ACCESS BY INDEX ROWID | T | | 767 | 420 | 
| 2 | BITMAP CONVERSION TO ROWIDS| | a | 767 | | 
| 3| BITMAP OR | | 1 | a | | 
Il* 4| BITMAP INDEX SINGLE VALUE| I N4 | 4 | 1 | 3 | 
| BITMAP INDEX SINGLE VALUE| IN6 | 1 | | 2 | 
|* 6| BITMAP INDEX SINGLE VALUE| I Ns | | :| 2 | 


4 - access("N4"=6) 
5 - access("N6"=11) 
6 - access("N5"=42) 


第 三 个 查询 与 第 一 个 类 似 。 这 次 ， 唯 一 的 不 同 是 n4 != 6 条 件 ( 替代 n4 = 6 )。 由 于 执行 计划 有 很 
大 不 同 ， 让 我 们 来 详细 看 一 下 。 最 初 ， 操 作 6 基 于 n5 列 在 该 列 查找 满足 n5 = 42 条 件 的 行 来 扫描 索引 。 
作为 结果 的 位 图 传递 给 操作 5。 接 着 ， 操 作 7 在 n6 列 的 索引 上 针对 n6 = 11 的 条 件 执 行 同样 的 扫描 。 一 旦 
两 个 索引 扫描 都 完成 ， 操 作 5 计 算 两 组 位 图 的 AND 条 件 并 传递 作为 结果 的 位 图 给 操作 4。 接 下 来 ， 操 作 8 
基于 n4 列 在 该 列 查找 满足 n4 = 6 条 件 (这 与 在 WHERE 子 句 中 指定 的 相反 ) 的 行 来 扫描 索引 。 作 为 结果 的 
位 图 传递 给 操作 4， 然 后 它 会 从 操作 5 传递 过 来 的 位 图 中 减 掉 它 们 。 接 着 ， 操 作 9 和 3 针对 n4 IS NULL 条 
件 执行 同样 的 扫描 。 这 一 步 很 必要 ， 因 为 NULL 值 并 不 满足 n4 != 6 的 条 件 。 最 后 ， 操 作 2 转 换 作 为 结果 
的 位 图 为 rowid 列 ， 结 果 操 作 1 使 用 它们 访问 表 : 

SELECT /*+ index combine(t i n4 i n5 i n6) */ * 


FROM +t 
WHERE n4 != 6 AND n5 = 42 AND n6 = 11 


| SELECT STATEMENT 

| TABLE ACCESS BY INDEX ROWID 
| BITMAP CONVERSION TO ROWIDS 
| BITMAP MINUS 

| BITMAP MINUS 
| 
| 

| 

| 


BITMAP AND 
BITMAP INDEX SINGLE VALUE| I 
BITMAP INDEX SINGLE VALUE| I_ 

I 
I 


BITMAP INDEX SINGLE VALUE | 
BITMAP INDEX SINGLE VALUE | 


6 - access("N5"=42) 
7 - access("N6"=11) 
8 - access("N4"=6) 
9 - access("N4" IS NULL) 
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总 之 ， 位 图 索引 可 以 高 效 地 合并 ， 而 且 在 合并 期 间 还 可 以 使 用 多 个 SQL 条 件 。 总 而 言 之 ， 它 们 非 
党 灵活。 由 于 这 些 特性 ， 它 们 对 报告 系统 非常 重要 ， 因 为 那里 的 查询 都 无 法 预先 知道 ( 固定 )。 


16. B 树 索引 的 位 图 计划 

上 市 介绍 的 位 图 计划 执行 得 很 好 , 它们 也 可 以 应 用 在 B 树 索引 上 。 数据 库 引 警 能 够 基于 B 树 索引 扫 
描 返 回 的 数据 ， 创 建 一 种 内 存 中 的 位 图 索引 。 下 面 的 查询 ， 与 在 复合 B 树 索引 部 分 使 用 的 一 样 ， 请 注 
意 执行 计划 中 的 BITMAP CONVERSION FROM RONIDS 操 作 负 责 转 换 : 

SELECT /*+ index combine(t i ni in2 i n3) */ * 


FROM + 
WHERE n1 = 6 AND n2 = 42 AND n3 = 11 


Id Operation | Name | Starts | A-Rows | Buffers 
0 | SELECT STATEMENT | 1 1 10 
1 TABLE ACCESS BY INDEX ROWID | 1 .| 10 
2 BITMAP CONVERSION TO ROWIDS | 1 了 9 
; BITMAP AND | 1 | 
4 BITMAP CONVERSION FROM ROWIDS | I 3 
路 -本 INDEX RANGE SCAN | I_N2 和 89 | 3 
6 BITMAP CONVERSION FROM ROWIDS | 1 1 3 
了 INDEX RANGE SCAN | 工 N3 1 164 3 
8 BITMAP CONVERSION FROM ROWIDS | 1 六 | 3 
到 和 INDEX RANGE SCAN | LN1 1 527 3 


5 - access("N2"=42) 
7 - access("N3"=11) 
9 - access("N1"=6) 


注意 B 树 索引 的 位 图 计划 也 与 位 图 索引 一 样 ， 只 能 在 企业 版 中 使 用 。 


17. 仅 索 引 扫描 

一 个 与 索引 相关 的 优化 技巧 是 数据 库 引擎 不 仅 可 以 从 索引 中 提取 rowid 列 来 访问 表 , 还 可 以 提取 存 
储 在 索引 中 的 列 数 据 。 因 此 ， 当 索引 包含 了 所 有 查询 需要 处 理 的 数据 时 ， 就 会 执行 仅 索引 扫描 
(index-only scan )。 这 对 减少 逻辑 读数 很 有 帮助 。 实 际 上 ， 仅 索引 扫描 不 访问 表 。 当 索引 的 群集 因子 高 
时 ， 这 对 索引 范围 扫描 非常 有 帮助 。 下 面 的 查询 举例 说 明 。 请 注意 没有 执行 访问 表 的 操作 : 

SELECT c1 FROM t WHERE c1 LIKE 'A%' 


| 0 | SELECT STATEMENT | | 1 | 
|* 1 | INDEX RANGE SCAN| I C1 | 1 | 119 | 11 | 
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1 - access("C1" LIKE “A% ) 
filter("C1" LIKE 'A%') 
如 果 SELECT 子 句 引 用 ni1 列 而 不 是 c1 列 ， 那 么 查询 优化 器 就 无 法 利用 仅 索引 扫描 。 请 注意 ， 在 下 面 
的 例子 中 , 查询 是 如 何 执行 了 130 个 逻辑 读 (针对 索引 执行 了 11 个 ， 针 对 表 执 行 了 119 个 ， 换 句 话 说， 
每 个 从 索引 中 获得 rowid 执 行 一 个 逻辑 读 ) 以 取 回 119 行 的 : 
SELECT n1 FROM t WHERE C1 LIKE 'A%' 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 3 | 119 | 130 | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 4 | 119 | 130 | 
|* 2 | INDEX RANGE SCAN | EC | 1 | 119 | 4 


2 - access("C1" LIKE 'A%') 
filter("C1" LIKE 'A%') 
在 这 类 情况 下 ， 为 了 使 用 仅 索 引 扫 描 ， 可 以 给 索引 增加 列 ， 使 它们 不 会 用 来 应 用 限制 。 理 想 做 法 
是 使 用 一 个 索引 键 创建 组 合 索引 来 包含 所 有 SQL 语句 引用 到 的 列 ( 也 称 为 覆盖 索引 )， 而 不 仅仅 是 在 
WHERE 子 句 中 使 用 的 列 。 换 句 话说， 你 “滥用 ”索引 来 存储 多 余 的 数据 ， 从 而 减 小 逻辑 读数 。 注 意 ， 
不 管 怎 样 索引 ， 引 导 列 必须 是 WHERE 子 名 引用 的 其 中 一 列 。 在 本 例 中 , 这 代表 在 cl 和 ni1 列 上 创 臣 复合 索 
引 。 使 用 这 个 索引 ， 同 样 的 查询 取 回 同样 多 的 行 只 需要 10 个 迎 辑 读 而 不 是 130 个 : 
SELECT n1 FROM t WHERE c1 LIKE 'A%' 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 鼻 | i119 .| 10 | 
|* 1 | INDEX RANGE SCAN| I CiN1 | 1 | 119 | 10 | 


1 - access("C1" LIKE 'A%') 
filter("C1" LIKE 'A%') 


警告 ”对 于 列表 分 区 表 来 说 ， 仅 在 分 区 键 是 索引 的 一 部 分 时 ， 查 询 优化 器 基于 仅 索 引 扫描 生成 的 执 
行 计划 来 分 解 IN 条 件 。 index_only_scan_list _part.sql 脚 本 提供 了 这 样 的 例子 。 对 于 范围 和 散 
列 分 区 表 来 说 ， 这 个 限制 不 存在 。 


即使 本 节 的 例子 都 是 基于 B 树 索引 ， 仅 索引 扫描 也 可 以 用 于 位 图 索引 。 


18. 索引 组 织 表 

创建 索引 组 织 表 (index-organized table ) 是 一 种 实现 仅 索 引 扫 描 的 特殊 方式 。 实 际 上 ， 这 类 表 的 
核心 概念 是 为 了 彻底 避免 产生 表 段 。 相 反 ， 所 有 数据 都 会 存储 在 基于 主键 的 索引 段 上 。 同 样 也 可 以 将 
部 分 数据 存储 在 溢出 段 ( overflow segment ) 上 。 然而 一 般 来 说 , 使 用 索引 组 织 表 的 好 处 已 经 不 存在 ( 除 
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非洲 出 段 很 少 被 访问 )。 当 创建 辅助 索引 ( secondary index， 除 了 主键 之 外 的 另 一 个 索引 ) 时 也 会 发 生 
相同 的 事 : 需要 访问 两 个 段 。 因 此 没有 必要 使 用 它 。 由 于 这 些 原因 ， 仅 当 满 足 两 个 需求 时 才 会 考虑 使 
用 索引 组 织 表 。 第 一 ， 表 通常 使 用 主键 访问 。 第 二 ， 所 有 数据 可 以 存储 在 索引 结构 中 (一行 最 多 可 以 
使 用 块 的 50% )。 除 此 之 外 ， 没 有 必要 使 用 它 。 

物理 rowid ( physical rowid ) 并 不 会 引用 索引 组 织 表 中 的 行 。 相反 , 它 由 逻辑 rowid ( logical rowid ) 
引用 。 这 类 rowid 由 两 部 分 组 成 : 第 一 ， 对 包含 插入 时 行 ( 键 ) 的 块 推测 。 第 二 ， 主 键 的 值 。 随 着 第 一 
次 推测 , 逻辑 rowid 会 访问 索引 组 织 表 , 希望 能 找到 行 插入 时 所 在 的 块 , 但 是 由 于 推测 并 不 会 在 发 生 块 
分 裂 时 更 新 ， 它 有 可 能 会 在 INSERT 和 UPDATE 语 句 执行 时 变 旧 。 如 果 推 测 正 确 ， 使 用 逻辑 rowid， 访 问 一 
行 数据 只 需 一 个 逻辑 读 。 万 一 推测 是 错误 的 ， 逻 辑 读 数 会 等 于 或 者 大 于 2 ( 一 个 是 通过 推测 无 用 的 访 
问 ， 加 上 使 用 主键 的 普通 访问 )。 自 然 地 ， 为 了 最 好 的 性 能 ， 重 要 的 是 正确 的 推测 。 要 评估 推测 的 正确 
性 ， 可 以 使 用 user indexes ( dba 、all 和 在 12.1 多 租户 环境 下 的 cdb 版 本 的 视图 也 包含 pct_direct_access 
列 ) 视图 中 的 pct_direct_access 列 ， 它 会 由 dbms_stats 包 来 更 新 。 这 个 值 提 供 了 针对 某 一 索引 推测 正 
确 的 百分比 。 下 面 的 例子 ,引用 自 iot_guess.sql 脚 本 ,不 仅 展 示 了 过 久 的 推测 会 影响 逻辑 读数 ， 也 展 
示 了 如 何 改变 这 种 次 优 的 情况 〈 请 注意 ,例子 中 使 用 的 索引 是 辅助 索引 ): 


SQL> SELECT pct direct access 
2 FROM user indexes 
3 WHERE table name = 'T' AND index name = 'I'; 


PCT_DIRECT_ACCESS 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 1 | 1| 1496 | 
| 1| SORT AGGREGATE | | 1 | 1| 1496 | 
|* 2| INDEX UNIQUE SCAN| T_PK | 1| 1000 | 1496 | 
|* 3| INDEX RANGE SCAN| I | 1 | 1000 | 6 | 


2 - access("N">0) 
3 - access("N">0) 


SQL> ALTER INDEX i UPDATE BLOCK REFERENCES; 
SQL> execute dbms stats.gather index stats(ownname => user, indname => 'i') 
SQL> SELECT pct direct access 
2 FROM user indexes 
3 WHERE table name = 'T' AND index name = 'I'; 
PCT_DIRECT ACCESS 


SQL> SELECT count(pad) FROM t WHERE n > 0; 
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| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 1 | 1| 1006 | 
| 1| SORTAGGREGATE | | 1 | 1| 1006 | 
| | INDEX UNIQUE SCAN| T_PK | | 1000 | 1006 | 
|* 3| INDEX RANGE SCAN| I | 1 | 4000 | 6 | 


2 - access("N">0) 
3 - access("N">0) 
逻辑 rowid 一 个 有 趣 的 副作用 是 辅助 索引 总 会 包含 主键 , 即使 它 没 有 明确 编 人 索引 。 下 面 的 例子 举 
例 说 明 只 靠 仅 索引 扫描 ， 数 据 库 引 擎 如 何 从 在 另 一 列 (mn ) 上 创建 的 辅助 索引 中 提取 主键 ( id ): 
SOL> SELECT id FROM 七 WHERE n = 42; 


| Id | Operation | Name | 


0 | SELECT STATEMENT | | 
1 | INDEX RANGE SCAN| I | 


1 - access("N"=42) 
除了 避免 访问 表 段 外 ， 另 外 索引 组 织 表 提供 了 两 个 不 应 该 低估 的 优势 。 第 一 ， 数 据 总 是 聚合 的 ， 
因此 基于 主键 的 范围 扫描 总 是 可 以 高 效 执行 ， 而 不 必 像 堆 表 那样 只 有 在 群集 因子 低 的 时 候 才 可 以 。 第 
二 个 优势 是 基于 主键 的 范围 扫描 总 是 按照 存储 在 主键 索引 中 的 数据 顺序 返回 数据 。 这 可 以 用 来 优化 
ORDER BY 操作 。 


19. 全 局 、 本 地 或 非 分 区 索引 

使 用 分 区 表 ， 通 常会 创建 本 地 分 区 索引 。 这 么 做 的 主要 优势 是 减少 索引 与 表 分 区 之 间 的 依赖 性 
例如 ， 当 分 区 增加 、 删 除 、 截 断 或 交换 时 ， 它 会 使 事情 变 得 简单 。 简单 来 说 ， 创 建 本 地 索引 通常 来 说 
是 有 好 处 的 。 然 而 ， 也 存在 不 能 或 者 不 建议 这 么 做 的 情况 


前 缀 与 非 责 缀 索引 
如 果 分 区 键 是 索引 列 的 左前 缓 ， 那 么 这 个 索引 就 是 前 缓 的 ， 并 且 对 于 子 分 区 索引 ， 子 分 区 键 包 
含 在 索引 键 中 。 而 本 地 索引 可 以 是 前 缓 或 者 非 前 缓 的 ， 只 能 创建 全 局 前 缓 索引 。 
根据 Oracle Database VLDB and Partitioning Guide 手 册 ， 非 前 组 索引 与 前 缓 索引 表现 不 同 。 实 际 
上 ， 我 从 未 见 过 因为 索引 是 非 前 组 的 而 导致 的 性 能 问题 。 我 的 建议 是 ,创建 最 明智 的 索引 而 不 用 考 
虑 它 是 否 是 前 组 索引 。 
RE Re 
第 一 个 问题 与 主键 和 唯一 索引 有 关 。 实 际 上 ， 基 于 本 地 索引 ， 它 们 的 键 必 须 包含 主键 。 尽 管 有 些 
时 候 可 行 ， 通常 有 改变 数据 库 逻 辑 设计 的 可 能 。 这 尤其 是 在 使 用 范围 分 区 时 。 因 此 ， 在 我 看 来 ， 这 应 
该 作为 最 后 的 手段 。 永 远 不 应 该 搞 乱 逻辑 设计 。 因 为 逻辑 设计 不 能 更 改 ， 仅 剩 下 其 他 两 种 可 能 。 第 一 
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是 创建 非 分 区 索引 。 第 二 是 创建 全 局 分 区 索引 。 后 者 仅 在 真正 有 优势 时 才 会 使 用 。 因 为 这 样 的 索引 通 
销 是 散 列 分 区 ， 然 而 ， 仅 在 索引 非常 大 或 者 索引 经 历 非 常 高 的 负载 时 才 值 得 这 么 做 。 总 之 ， 为 了 支持 
主键 和 唯一 索引 而 创建 非 分 区 索引 并 不 常见 。 

本 地 分 区 索引 的 第 二 个 问题 是 对 于 不 能 利用 分 区 裁剪 的 SQL 语句 ， 它 们 可 以 使 性 能 变 得 糟糕 。 在 
本 章 之 前 的 “范围 分 区 ”部 分 中 描述 过 导致 这 种 情况 的 原因 。 它 对 索引 扫描 的 影响 或 许 会 非常 高 。 下 
面 的 例子 ， 基于 图 13-5 的 范围 分 区 表 ， 展示 了 可 能 会 有 的 问题 。 首先, 创建 非 分 区 索引 。 使 用 它 查 询 ， 
返回 一 行 执 行 了 4 个 逻辑 读 。 请 注意 ，TABLE ACCESS BY GLOBAL INDEX ROWID 操 作 表 明 rowid 来 自 全 局 或 
非 分 区 索引 : 


SQL> CREATE INDEX i ON t (n3); 


SQL> SELECT * FROM t WHERE n3 = 3885; 


| Id | Operation | Name | Starts | A-Rows | Buffers 

| 0 | SELECT STATEMENT | | | | 4 | 
| 1 | TABLE ACCESS BY GLOBAL INDEX ROWID| T | 1 | 1 | 4 | 
|* 2 | INDEX RANGE SCAN ER 和 1 | 1 | 3 | 


2 - access("N3"=3885) 

对 于 该 实验 的 第 二 部 分 ， 重建 了 索引 。 这 次 是 本 地 索引 。 由 于 表 有 48 个 分 区 ， 所 以 索引 也 有 48 
个 分 区 。 因 为 实验 查询 并 不 包含 基于 分 区 键 上 的 限制 ,所 以 不 会 发 生 分 区 裁 前 。 这 可 以 由 PARTITION 
RANGE ALL 操 作 以 及 Pstart 和 Pstop 列 来 证 实 。 同 样 注意 到 TABLE ACCESS BY LOCAL INDEX RONID 操 作 
表明 rowid 来 自 本 地 分 区 索引 。 执行 计划 的 问题 是 代替 像 上 个 案例 那样 执行 单 索引 扫描 , 这 次 索引 扫 
描 是 针对 每 个 分 区 执行 的 (注意 操作 2 和 操作 3 的 Starts 列 )。 因此 ， 即 使 只 取 回 了 一 行 ，50 个 逻辑 读 
也 是 必要 的 : 

SQL> CREATE INDEX i ON t (n3) LOCAL; 

SQL> SELECT * FROM t WHERE n3 = 3885; 


| Id | Operation | Name | Starts | Pstart| Pstop | A-Rows | Buffers 

| 0 | SELECT STATEMENT | | 1 | | | 1 ] 50 | 
| 1 | PARTITION RANGE ALL | | 1 | EL | 要 1 | 50 | 
| 2 | TABLE ACCESS BY LOCAL INDEX ROWID| T | 48 | 1| 48| 二 50 | 
| 特色 | INDEX RANGE SCAN 上 这 | 48 | | 48 | ,| 49 | 


3 - access("N3"=3885) 
总 之 ， 不 使 用 分 区 裁 前 ， 逻 辑 读 数 会 按照 分 区 数 成 比例 增长 。 因 此 ， 正 如 之 前 指出 的 ， 有 时 使 用 
非 分 区 索引 要 比分 区 索引 好 。 或 者 ， 作 为 折 中 方案 ， 应 该 限制 分 区 数量 。 注 意 ， 有 时 你 没有 选择 。 比 
如 ， 位 图 索引 仅 可 以 作为 本 地 索引 创建 。 
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20. 不 可 见 索引 

从 11.1 版 本 之 后 ， 有 个 索引 属性 可 以 用 来 指定 索引 是 否 对 查询 优化 器 可 见 。 默 认 情况 下 ， 索 引 是 
可 见 的 。 万 一 索引 不 可 见 ， 当 索引 基于 的 数据 表 发 生 修 改 时 ， 就 需要 常规 维护 了 ， 但 是 查询 优化 器 无 
法 在 执行 计划 生成 期 间 利 用 它 。 因 为 不 可 见 索引 是 定期 维护 的 , 基于 唯一 索引 的 约束 仍然 会 定期 执行 ， 
即使 它们 基于 的 索引 不 可 见 。 


警告 在 11.1 版 本 中 ,索引 的 不 可 见 并 不 是 全 部 。 实 际 上 ， 在 两 个 突 发 情况 下 查询 优化 器 可 以 利用 不 
可 见 索引 。 第 一 ， 即 使 不 可 见 索 引 不 会 包含 在 执行 计划 中 ， 查 询 优化 器 也 可 以 使 用 统计 信息 
关联 它 来 提高 其 估 值 。invisible index_stats.sql 脚 本 示范 了 这 样 的 案例 。 第 二 ， 对 于 未 加 索 
引 的 外 键 ， 数 据 库 引擎 能 够 利用 不 可 见 索引 来 避免 错误 的 争 用 。 


下 面 的 例子 基于 invisible_ index.sql 脚 本 ,展示 了 如 何 使 索引 不 可 见 以 及 这 样 的 操作 如 何 对 指定 
查询 产生 影响 : 
SQL> SELECT * FROM t WHERE id = 42; 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
| 1 | TABLE ACCESS BY INDEX ROWID| T | 
|* 2 | INDEX UNIOUE SCAN | TPK | 


2 - access("ID"=42) 
SQL> SELECT visibility FROM user indexes WHERE index name = 'T_PK'; 


VISIBILITY 


VISIBLE 
SOL> ALTER INDEX 七 pk INVISIBLE; 
SQL> SELECT visibility FROM user indexes WHERE index name = 'T_PK'; 


VISIBILITY 


INVISIBLE 


SQL> SELECT * FROM t WHERE 41d = 42; 


| Id | Operation | Name | 


0 | SELECT STATEMENT | | 
4 | TABLE XECESS FULL| 下 | 


1 - filter("ID"=42) 
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在 以 下 两 种 情况 下 调整 或 创建 不 可 见 索引 是 有 益 的 。 
口 无 论 是 否 删除 已 存在 的 索引 都 不 会 影响 访问 性 能 。 这 在 需要 删除 的 索引 很 大 时 很 有 用 。 实 际 
上 ， 无 法 实验 删除 一 个 大 索引 ， 当 你 事后 发 现 删除 索引 是 个 错误 的 时 候 ， 将 需要 花费 太 长 时 
间 和 太 多 资源 来 重建 它 。 
口 创建 索引 但 不 使 它 会 立即 对 查询 优化 器 生效 。 
默认 情况 下 ， 查询 优化 器 承认 索引 的 可 见 性 。 这 是 因为 ， 默认 情况 下 会 将 初始 化 参数 
optimizer use invisible indexes 设 置 为 FALSE。 如 果 在 系统 级 别 或 者 会 话 级 别 上 将 这 个 参数 设置 为 
TRUE， 查 询 优化 器 就 允许 不 可 见 索引 为 可 见 。 自 从 11.1.0.7 版 本 开始 ， 也 可 以 在 SQL 语句 中 增加 (no_) 
use_invisible indexes hint 来 控制 查询 优化 器 是 否 承 认 索 引 的 可 见 性 。 


警告 ra Availabilty Overview 手 册 : bie a ie 索引 , 但 是 除非 你 明确 使 用 hint 
定 索引 ， 否 则 优化 器 并 不 会 使 用 它 。” 不 幸 的 是 ， 这 向 话 有 错误 。 问题 是 index hint 无 法 用 来 改 
pet ee 仅 (no_ ep finisible indexes hint 可 以 影响 不 可 见 索 引 的 可 见 度 。 


直到 11.2 版 本 ( 包括 该 版 本 ), 在 同一 组 列 上 不 能 创建 多 个 索引 ( 如 果 你 尝试 这 么 做 ,数据库 引擎 
会 报 ORA-01408 )。 从 12.1 版 本 开始 ， 这 个 限制 被 取消 了 。 实 际 上 , 在 同一 组 列 上 创建 多 个 索引 ,在 同 
一 时 间 只 有 其 中 一 个 索引 可 见 。 这 种 可 能 性 对 于 应 用 来 说 必须 处 理 成 高 可 用 ， 这 在 改 伙 过 引 的 唯一 性 、 
类 型 (B 树 或 位 图 ) 和 分 区 而 不 需要 计划 停机 时 间 时 很 有 用 。 不 使 用 这 个 特性 ， 当 删除 和 重建 索引 时 
或 许 会 需要 停止 其 他 的 高 可 用 应 用 。 下 面 的 例子 ， 引 用 自 multiple indxes;sql 脚 本 的 输出 ， 举 例 说 明 
这 个 特性 。 

(1) 设置 初始 化 对 象 : 

SQL> CREATE TABLE t (n1 NUMBER, n2 NUMBER, n3 NUMBER); 


SQL> CREATE INDEX i i ON t (n1); 

(2) 在 同样 的 列 (nl1 ) 上 不 支持 创建 与 上 一 个 一 致 的 不 可 见 索引 ( 请 注意 新 索引 是 唯一 的 ): 
SQL> CREATE UNIQUE INDEX i ui ON t (n1); 

CREATE UNIQUE INDEX i ui ON t (na) 


ERROR at line 1: 
ORA-01408: such column list already indexed 


(3) 可 以 创建 多 个 不 可 见 索引 ( 请 注意 每 个 索引 的 不 同 ): 
SQL> CREATE UNIQUE INDEX i ui ON t (n1) INVISIBLE; 
SQL> CREATE BITMAP INDEX i bi ON t (n1) INVISIBLE; 


SQL> CREATE INDEX i hpi ON t (n1) INVISIBLE 
2 GLOBAL PARTITION BY HASH (n1) PARTITIONS 4; 


SQL CREATE INDEX i rpi ON t (n1) INVISIBLE 
2 GLOBAL PARTITION BY RANGE (n1) ( 
3 PARTITION VALUES LESS THAN (10), 
4 PARTITION VALUES LESS THAN (MAXVALUE) 
5 六 
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(4) 通过 使 日 索引 不 可 见 并 使 新 索引 可 见 ， 在 两 个 索引 之 间 切 换 : 
SOL> ALTER INDEX i i INVISIBLE; 


SQL> ALTER INDEX i ui VISIBLE; 


21. 局 部 索引 
出 于 性 能 考虑 ， 有 时 并 不 需要 将 表 中 的 所 有 数据 索引 化 。 尤 其 是 大 范围 分 区 表 包 含 很 长 的 特定 历 
史 时 间 数 据 ( 比如 订单 或 通话 记录 ) 时 。 例 如 ， 可 能 仅 需要 对 前 一 天 的 数据 创建 索引 ， 或 最 近 一 周 的 
数据 ， 并 且 把 所 有 过 期 的 数据 从 索引 中 删除 。 这 样 的 索引 叫 作 局 部 索引 (partial index )。 在 正确 的 场 
合 使 用 它们 可 以 节省 许多 不 必要 分 配 的 磁盘 空间 。 
即使 一 直到 11.2 版 本 ( 包括 该 版 本 )， 使 用 一 些 特 别 的 技巧 也 可 以 使 用 一 些 局 部 索引 ， 仅 从 12.1 版 
本 以 后 ，Oracle 数 据 库 提供 正规 语法 来 支持 局 部 索引 。12.1 版 本 引入 语法 的 基本 概念 ， 可 以 在 表 或 者 
分 区 级 别 设置 数据 是 否 使 用 索引 。 
下 面 的 例子 基于 partial_index.sql 脚 本 ,展示 了 如 何 禁 用 除了 设置 INDEXING ON 属性 以 外 的 其 他 所 
有 分 区 的 索引 功能 ( 显然 你 也 可 以 在 表 级 别 设置 INDEXING ON， 并 为 指定 分 区 设置 INDEXING OFF ): 
CREATE TABLE t ( 
id NUMBER NOT NULL， 
d DATE NOT NULL, 


n NUMBER NOT NULL， 
pad VARCHAR2(4000) NOT NULL 


) 
INDEXING OFF 
PARTITION BY RANGE (d) ( 


PARTITION t jan 2014 VALUES 
PARTITION t feb 2014 VALUES 
PARTITION t mar 2014 VALUES 
PARTITION t apr 2014 VALUES 
PARTITION t_ may 2014 VALUES 
PARTITION t jun 2014 VALUES 
PARTITION t jul 2014 VALUES 
PARTITION t aug 2014 VALUES 
PARTITION t sep 2014 VALUES 
PARTITION t oct 2014 VALUES 
PARTITION t_nov 2014 VALUES 
PARTITION t dec 2014 VALUES 


LESS THAN (to date('2014-02-01' 
LESS THAN (to date('2014-03-01' 
LESS THAN (to date('2014-04-01' 
LESS THAN (to date('2014-05-01' 
LESS THAN (to date('2014-06-01' 
LESS THAN (to date('2014-07-01'," 
LESS THAN (to date('2014-08-01' 
LESS THAN (to date('2014-09-01"' 
LESS THAN (to date('2014-10-01' 
LESS THAN (to date('2014-11-01' 
LESS THAN (to date('2014-12-01' 
LESS THAN (to date('2015-01-01" 


3 
» 
>》 
» 
3 


2 
» 
3 
9 
了 


‘yyyy-mm-dd' )), 
‘yyyy-mm-dd' )), 
‘yyyy-mm-dd' )), 
‘yyyy-mm-dd' )), 
“yyyy-mm-dd )), 


yyyy-mm-dd' )), 


‘yyyy-mm-dd' )), 
‘yyyy-mm-dd' )), 
"yyyy-mm-dd' ))， 
‘yyyy-mm-dd' )), 
‘yyyy-mm-dd' )), 
‘yyyy-mm-dd')) INDEXING ON 


当 索 引 创建 后 ， 可 以 指定 是 遵守 索引 属性 ( INDEXING PARTIAL ) 还 是 不 遵守 ( INDEXING FULL， 这 
是 默认 值 )。 下面 的 SQL 语句 展示 如 何 创建 局 部 索引 : 

CREATE INDEX i ON t (d) INDEXING PARTIAL 

使 用 局 部 索引 的 关键 要 求 是 需要 将 数据 存储 在 分 区 表 中 。 索引 是 未 分 区 .本 地 还 是 全 局 的 都 没关系 。 
除了 这 些 之 外 ， 只 有 使 用 INDEXING ON 存储 在 分 区 中 的 行 才 会 被 索引 。 使 用 像 上 个 例子 那样 创建 的 表 和 索 
引 ， 查 询 优化 器 不 会 限制 通过 全 表 扫 描 或 索引 扫描 来 访问 所 有 数据 。 相 反 ， 它 可 以 利用 表 扩 展 查 询 转 换 
( 请 参考 第 6 章 )， 从 而 基于 数据 是 否 有 索引 来 生成 不 同 的 访问 路 径 。 下 面 的 例子 图 示 了 这 一 情形 。 
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SQL> SELECT * 


2 FROMt 

3 WHERE d BETWEEN to date('2014-11-30 23:00:00','yyyy-mm-dd hh24:mi:ss') 

4 AND to date('2014-12-01 01:00:00','yyyy-mm-dd hh24:mi:ss'); 
| Id | Operation | Name Pstart| Pstop 
| 0 | SELECT STATEMENT 
| 1 | VIEW | VW_TE 2 
| 2| UNION-ALL | 
| 3| TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED| T 12 12 
a | INDEX RANGE SCAN | I 
| 至 PARTITION RANGE SINOLE | 41 Ty 
财 奈 .| TABLE ACCESS FULL 最 14 11 


4 - access("T"."D">=TO DATE(' 2014-12-01 00:00:00', 'syyyy-mm-dd 
hh24:mi:ss') AND "D"<=TO DATE(' 2014-12-01 01:00:00', 'syyyy-mm-dd 
hh24:mi:ss')) 

6 - filter("D">=TO DATE(' 2014-11-30 23:00:00', 'syyyy-mm-dd 
hh24:mi:ss')) 


13.3.3 ” 单 表 散 列 群集 访问 


实践 中 ,很 少 有 数据 库 使 用 单 表 散 列 群集 。 事实 上 ， 当 它们 按照 正确 的 大 小 排列 并 通过 群集 键 上 
的 等 式 条 件 访问 时 , 它们 能 提供 非常 好 的 性 能 。 这 有 两 个 原因 。 第 一 , 它们 不 需要 分 离 的 访问 结构 ( 比 
如 ， 索 引 ) 来 定位 数据 。 实 际 上 ， 和 群集 键 就 足够 用 来 定位 它 。 第 二 ， 所 有 关联 群集 键 的 数据 都 聚合 在 
一 起 。 这 两 个 优势 也 在 本 章 之 前 部 分 的 图 13-3 和 图 13-4 中 通过 实验 演示 过 。 

单 表 散 列 群集 用 来 实现 通过 指定 键 频繁 地 ( 理想 上 ， 总 是 ) 查找 表 。 基 本 上 可 以 在 索引 组 织 表 上 
使 用 同样 的 方法 。 然 而 ， 它 们 之 间 有 些 主要 区 别 。 表 13-4 列 出 了 单 表 散 列 群集 与 索引 组 织 表 相 比 的 主 
要 优势 和 劣势 。 主 要 的 劣势 是 单 表 散 列 群集 需要 准确 设置 大 小 才能 使 用 。 


表 13-4 ” 单 表 散 列 群集 与 索引 组 织 表 的 比较 


优势 劣势 
更 好 的 性 能 (如 果 通 过 群集 键 访问 并 正确 设置 大 小 ) 需要 设置 大 小 ， 忽 略 散 列 冲 突 并 且 浪 费 空间 
群集 键 或 许 与 主键 不 同 不 支持 分 区 
不 支持 LOB 列 


当 单 表 散 列 群集 通过 群集 键 访问 时 ， 执 行 计划 中 会 出 现 TABLE ACCESS HASH 操 作 。 它 通过 群集 键 直 
接 访问 包含 需要 数据 的 块 (也 可 能 是 多 个 )。 下 面 引用 自 hash_cluster.sql 脚 本 的 数据 ， 举 例 说 明 : 
SELECT * FROM t WHERE id = 6 


| Id | Operation | Name | Starts | A-Rows | Buffers 


| 0 | SELECT STATEMENT | | 1 | 站 1 | 
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1 - access("ID"=6) 
除了 等 式 条 件 ， 其 他 条 件 允 许 通 过 群集 键 访问 数据 的 IN 条 件 。 当 指定 IN 时 ， 根 据 数据 库 版 本 ， 操 
作 会 出 现在 执行 计划 中 。 实 际 上 ， 一 直到 11.1 版 本 ( 包括 该 版 本 ) 使 用 的 都 是 CONCATENATION 操 作 ， 从 
11.2 版 本 以 后 使 用 INLIST ITERATOR 替 代 。 这 两 个 操作 的 每 个 子 操作 都 执行 一 次 来 获取 特定 的 群集 键 。 
下 面 的 执行 计划 在 11.1.0.7 版 本 中 生成 : 


SELECT * FROM 七 WHERE id IN (6, 8, 19, 28) 


Id | Operation Name | Starts | A-Rows | Buffers 
0 | SELECT STATEMENT | 于 | 4 | 4 
1 | CONCATENATION | 1 | 4 | 4 
+ 2 | TABLE ACCESS HASH| T | 1 | 1 | 1 
* 3 | TABLE ACCESS HASH| T | a | 1 | 1 
* 4 | TABLE ACCESS HASH| T | 1 | 1 | 1 
* 5 | TABLE ACCESS HASH| T | 1 | | 1 
2 - access("ID"=28) 
3 - access("ID"=19) 
4 - access("ID"=8) 
5 - access("ID"=6) 
下 面 的 执行 计划 在 11.2.0.1 版 本 中 生成 : 
SELECT * FROM t WHERE id IN (6, 8, 19, 28) 
| Id | Operation | Name | Starts | A-Rows | Buffers | 


0 | SELECT STATEMENT | | 1 | 页 | 4 | 
| 1| INLIST ITERATOR | | 1 | 4 | 4 | 
2 | TABLE ACCESS HASH| T | 4 | 4 | 4 | 
2 - access(("ID"=6 OR "ID"=8 OR "ID"=19 OR "ID"=28)) 
重点 需要 强调 的 是 ， 如 果 没有 使 用 索引 ， 其 他 所 有 条 件 都 会 导致 全 表 扫 描 。 例 如 ， 下 面 的 查询 ， 
在 NHERE 子 句 中 包含 范围 条 件 ， 使 用 索引 : 


SELECT * FROM t WHERE id < 6 


| Id | Operation | Name | Starts | A-Rows | Buffers | 
| 0 | SELECT STATEMENT | | 1 | 5 | 5 | 
| 1| TABLE ACCESS BY INDEX ROWID| T | 1 | 5 | 5 | 
|* 2 | INDEX RANGE SCAN | TPK | | 5 | 3 | 


2 - access("ID"<6) 
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请 注意 , 群集 有 特定 的 对 象 统计 信息 用 来 提供 每 个 键 的 平均 块 数 。 可 以 通过 user_clusters 视 图 的 
avg_blocks_per key 列 来 显示 ( 当然 , 还 有 dba、all 和 在 12.1 多 租户 环境 下 的 cdb 视 图 版 本 可 用 )。 不 幸 
的 是 ， 它 的 统计 信息 并 不 是 由 dbms_stats 包 收集 的 ， 反 而 需要 你 执行 ANALYZE CLUSTER 语句 。 为 了 更 准 
确 地 估量 值 ， 别 忘 了 收集 它 。 


13.4 小结 


本 章 不 仅 介绍 了 在 选择 高 效 访问 路 径 时 选择 性 的 重要 性 , 也 介绍 了 用 于 访问 在 单 表 中 存储 的 数据 
的 不 同方 法 。 为 此 ， 弱 选择 性 的 SQL 语 句 应 该 使 用 全 表 扫 描 、 全 分 区 扫描 或 全 索引 扫描 。 也 讨论 了 为 
了 高 效 执行 强 选 择 性 的 SQL 语句 ， 选 择 基 于 rowid 、 索 引 和 单 表 散 列 群 集 的 访问 路 径 。 

本 章 仅 介绍 了 处 理 单 表 的 SQL 语句 。 实 际 上 ， 多 表 联 接 很 常见 。 为 了 解决 这 个 问题 ， 下 一 章 将 介 
绍 三 种 基本 联接 方法 及 其 利 浆 。 换 句 话 说， 下 章 将 介绍 该 在 何 时 使 用 哪 种 联接 方法 。 


第 14 章 | 
优化 联接 


当 一 条 SQL 语句 引用 多 张 表 时 ， 查 询 优化 器 必须 决定 的 事情 ， 除 了 每 张 表 的 访问 路 径 以 外 .还 有 
表 联 接 的 顺序 以 及 使 用 的 联接 方法 。 查 询 优化 锅 的 目标 是 尽 可 能 早 地 过 滤 邱 不 必要 的 数据 ， 以 便 最 小 
化 需要 处 理 的 数据 总 量 。 

本 章 首先 会 定义 一 些 关 键 术 语 并 解释 三 种 基本 的 联接 方法 ( 散 套 循环 、 合 并 联接 和 散 列 联接 ) 如 
何 工 作 。 接 下 来 会 给 出 一 些 如 何 选 择 联接 方法 的 建议 。 最 后 ， 会 介绍 诸如 分 区 智能 联接 和 星 型 转换 这 
样 的 优化 技术 。 


注意 ”在 本 章 中 ， 多 条 SQL 语句 包含 hint 这 么 做 不 仅 是 向 你 展示 哪 一 个 hint 会 导致 哪 一 个 执行 计划 ， 


而 且 还 为 了 向 你 展示 它们 的 用 法 。 无论 如 何 ， 既 没有 提供 真实 的 参考 也 没有 提供 完整 的 语法 
可 以 在 Oracle Database SOL Reference 手 册 的 第 2 章 中 找到 相关 信息 


14.1 定义 


为 避免 误解 ， 接 下 来 的 小 节 会 定义 一 些 贯 穿 本 章 的 术语 和 概念 。 尤 其 是 我 会 涉及 不 同类 型 的 联接 
树 、 限 制 条 件 和 联接 条 件 之 间 的 区 别 ， 以 及 不 同类 型 的 联接 。 


14.1.1 联接 树 


数据 库 引 擎 支持 的 所 有 联接 方法 在 同一 时 刻 都 是 只 会 处 理 两 组 数据 。 这 两 组 数据 被 称 为 左 输入 和 
右 输 入 。 以 这 样 的 方式 命名 它们 是 因为 当 使 用 图 示 ( 见 图 14-1 ) 时 ,输入 的 其 中 一 个 放置 在 联接 的 左 
边 (TI ) 而 男 一 个 放置 在 右边 ( T2 )。 注意 ,在 图 示 中 ,位 于 左边 的 节点 要 先 于 右边 的 节点 执行 。 
结果 集 


T1 T2 
图 14-1 ”两 组 数据 之 间 联 接 的 图 示 
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当 必 须 联接 超过 两 组 的 数据 时 ， 查询 优化 器 会 评估 联接 树 ( Join Tree ), 被 查询 优化 器 利用 的 联接 
树 的 类 型 会 在 接 下 来 的 四 个 小 节 中 介绍 。 
1. 左 深 树 
左 深 树 (left-deep tree )， 如 图 14-2 所 示 ， 是 一 种 每 个 联接 都 有 一 张 表 ( 也 就 是 说 ， 不 是 由 上 一 次 
联接 生成 的 结果 集 ) 作为 它 的 右 输 入 的 联接 树 。 这 是 最 经 常 被 查询 优化 器 选择 的 联接 树 。 
结果 集 


T1 T2 
图 14-2 ”在 左 深 树 中 ， 右 输入 永远 是 一 张 表 


下 面 的 执行 计划 演示 了 图 14-2 描 述 的 联接 树 。 注 意 ， 每 个 联接 操作 ( 就 是 第 5 行 、 第 6 行 和 第 7 行 ) 
的 第 二 个 子 操作 ( 那 就 是 ， 右 输入 ) 永远 是 一 张 表 : 


Id Operation Name 
0 | SELECT STATEMENT 
1 HASH JOIN 
2 HASH JOIN 
3 HASH JOIN 
4 TABLE ACCESS FULL| T1 
5 TABLE ACCESS FULL| T2 
6 TABLE ACCESS FULL | T3 
7 TABLE ACCESS FULL T4 


2. 右 深 树 
右 深 树 (iight-deep tree )， 如 图 14-3 所 示 ， 是 一 种 每 个 联接 都 有 一 张 表 作为 它 的 左 输入 的 联接 树 。 
这 个 联接 树 很 少 会 被 查询 优化 器 选择 。 
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T1 


2 


T3 T4 
图 14-3 ”在 右 深 树 中 ， 左 输入 永远 是 一 张 表 


下 面 的 执行 计划 演示 了 图 14-3 描 述 的 联接 树 。 注 意 ， 每 个 联接 操作 ( 就 是 第 2 行 、 第 4 行 和 第 6 行 ) 
的 第 一 个 子 操作 ( 那 就 是 ， 左 输入 ) 永远 是 一 张 表 : 


Id | Operation | Name 

0 | SELECT STATEMENT | 

1 HASH JOIN | 

2 TABLE ACCESS FULL | T1 

3 HASH JOIN | 

4 TABLE ACCESS FULL | T2 

5 HASH JOIN 

6 TABLE ACCESS FULL| T3 

了 TABLE ACCESS FULL| T4 


3. 曲折 树 

曲折 树 〈 zig-zag tree )， 如 图 14-4 所 示 ， 这 种 联接 树 的 每 个 联接 都 至 少 有 一 张 表 作为 输入 ， 但 
是 这 些 基于 表 的 输入 有 时 候 位 于 左 侧 有 时 候 位 于 右 侧 .这 种 类 型 的 联接 树 通常 不 会 被 查询 优化 器 所 
使 用 。 

下 面 的 执行 计划 演示 了 图 14-4 描 述 的 联接 树 : 


0 | SELECT STATEMENT | 

1 HASH JOIN | 
HASH JOIN 

3 TABLE ACCESS FULL | T1 
4 

5 


HASH JOIN 
TABLE ACCESS FULL| T2 
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| 6 | TABLE ACCESS FULL| T3 | 
| 7 | TABLE ACCESS FULL | T4 | 
结果 集 

T4 
| 

T2 T3 

图 14-4 在 曲折 树 中 ， 两 个 输入 中 至 少 有 一 个 是 一 张 表 
4. 浓密 树 


浓密 树 ( bushy tree )， 如 图 14-5 所 示 ， 是 一 个 可 能 拥有 两 个 输入 都 不 是 表 的 联接 的 联接 树 。 换 名 
话说 , 这 种 树 的 结构 是 完全 自由 的 。 查 询 优化 器 只 会 在 没有 其 他 选项 可 用 时 才 会 选择 这 种 类 型 的 联接 
树 。 通 常 在 不 可 合并 的 视图 或 子 查 询 出 现 的 时 候 会 发 生 这 种 情况 。 

结果 集 


T1 13 T4 
图 14-5 浓密 树 的 结构 是 完全 自由 的 


下 面 的 执行 计划 演示 了 图 14-5 描 述 的 联接 树 。 注 意 ， 联 接 操 作 1 的 子 操作 是 为 外 两 个 联接 操作 的 
结果 集 : 
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Id Operation Name | 
0 | SELECT STATEMENT 
1 HASH JOIN 
2 VIEW 
3 HASH JOIN 
4 TABLE ACCESS FULL| T1 
5 TABLE ACCESS FULL| T2 
6 VIEW 
7 HASH JOIN 
8 TABLE ACCESS FULL| T3 
9 TABLE ACCESS FULL| T4 


14.1.2 ”联接 的 类 型 


有 两 种 类 型 用 于 指定 联接 的 语法 。 经 典 语 法 , 是 在 很 早 的 SQL 标 准 ( SQL-86 ) 中 指定 的 , 使 用 FROM 
子 句 和 WHERE 子 句 两 者 一 起 来 指定 联接 。 较 新 的 语法 ， 第 一 次 是 在 SQL-92 中 可 用 ， 仅 使 用 FROM 子 句 来 
指定 一 个 联接 。 新 的 语法 有 时 称 作 ANSI 联 接 语 法 。 不 管 怎 样 ， 从 SQL 标 准 的 视角 来 看 两 种 语法 类 型 都 
是 有 效 的 。 在 Oracle 数 据 库 中 ， 因 为 历史 原因 ， 和 合用 最 频繁 的 语法 是 经 典 的 那 种 。 事 实 上 ， 不 仅 很 多 
的 开发 人 员 和 DBA 习 惯 这 种 语法 ,而 且 很 多 应 用 程序 也 是 使 用 它 开 发 的 。 虽 然 如 此 ,新 的 语法 提供 经 
典 语法 不 支持 的 选项 。 接 下 来 的 小 节 会 基于 两 种 语法 提供 案例 。 这 里 使 用 的 所 有 查询 都 作为 例子 在 
join_types.sql 脚 本 中 提供 。 


注意 这 一 节 中 描述 的 联接 类 型 并 非 互相 排斥 的 。 一 个 给 定 的 联接 可 能 会 属于 不 止 一 种 类 别 。 例 如 ， 
认为 一 个 内 联接 也 是 一 个 自 联 接 是 完全 可 信 的 。 


1. 交叉 联接 

交叉 联接 ( cross join )， 也 称 作 笛 卡 儿 积 ( Cartesian product )， 是 将 一 张 表 的 每 一 行 与 另外 一 张 表 
的 每 一 行 组 合 的 操作 。 这 种 类 型 的 操作 会 在 下 面 的 查询 中 列举 的 两 种 情况 下 出 现 。 第 一 个 使 用 经 典 联 
接 诸 法 ( 没有 指定 联接 条 件 ): 

SELECT emp.ename，dept.dname FROM emp，dept 

第 二 个 使 用 新 的 联接 语法 ( 使 用 了 CR0SS JOIN ): 

SELECT emp.ename, dept.dname FROM emp CROSS JOIN dept 

在 现实 中 ,交叉 联接 几乎 是 不 需要 的 。 虽 然 如 此 ， 后 者 的 语法 能 更 好 地 证 明 开发 者 的 意图 。 事 实 
上 上， 明确 指定 是 有 好 处 的 。 使 用 前 者 ， 则 不 清楚 是 否 是 写 下 该 SQL 语句 的 那个 人 忘记 了 WHERE 子 句 。 

2. 9 联接 

0 联接 ( theta join ) 等 同 于 在 一 个 交叉 联接 的 结果 集 上 执行 一 个 选择 。 换 句 话 说， 取代 返回 一 张 
表 的 每 一 行 与 男 一 张 表 的 每 一 行 的 组 合 ， 只 有 满足 联接 条 件 的 记录 会 被 返回 。 下 面 的 两 个 查询 是 这 种 
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类 型 联接 的 例子 : 


SELECT emp.ename, salgrade.grade 
FROM emp, salgrade 
WHERE emp.sal BETWEEN salgrade.losal AND salgrade.hisal 


SELECT emp.ename, salgrade.grade 
FROM emp JOIN salgrade ON emp.sal BETWEEN salgrade.losal AND salgrade.hisal 


9 联接 也 被 称 作 内 联接 ( inner join )。 在 上 面 的 查询 中 使 用 的 是 新 的 联接 语法 ， 关 键 字 INNER 被 省 
略 了 ， 但 其 实 可 以 对 其 进行 显 式 编码 ， 如 下 例 所 示 


SELECT emp.ename, salgrade.grade 
FROM emp INNER JOIN salgrade ON emp.sal BETWEEN salgrade.losal AND salgrade.hisal 


3. 等 值 联 接 

等 值 联接 ( equi-join ) 是 一 种 只 在 联接 条 件 中 使 用 等 值 运算 符 的 特殊 类 型 的 内 联接 。 下 面 的 两 个 
查询 是 例子 : 

SELECT emp.ename, dept.dname 


FROM emp, dept 
WHERE emp.deptno = dept.deptno 


SELECT emp.ename, dept.dname 
FROM emp JOIN dept ON emp.deptno = dept.deptno 


4. 自 联 接 
自 联接 ( self-join ) 一 种 一 张 表 联 接 自己 的 特殊 类 型 的 内 联接 。 下 面 的 两 个 查询 是 这 种 联接 的 例子 。 


注意 ，emp 表 在 FROM 子 句 中 被 引用 了 两 次 : 


SELECT emp.ename, mgr.ename 
FROM emp, emp mgr 
WHERE emp.mgr = mgr.empno 


SELECT emp.ename, mgr.ename 
FROM emp JOIN emp mgr ON emp.mgr = mgr.empno 


5. 外 联接 

外 联接 ( outer join ) 扩展 内 联接 的 结果 集 。 事 实 上 ， 通 过 一 个 外 联接 ， 即 使 在 另外 一 张 表 中 没有 
找到 匹配 的 值 也 会 返回 一 张 表 ( 保留 表 ) 的 所 有 记录 。NULL 值 会 与 那 张 不 包含 任何 匹配 数据 的 表 返 回 
的 列 进行 关联 。 举 个 例子 , 在 上 一 部 分 ( 自 联 接 ) 中 的 查询 不 会 返回 emp 表 的 所 有 数据 , 因为 雇员 KING， 
也 就 是 主席 , 没有 管理 者 。 要 使 用 经 典 语法 指定 外 联接 , 必须 使 用 一 个 Oracle 的 扩展 ( 基于 运算 符 (+) )。 
下 面 的 查询 是 一 个 例子 : 


SELECT emp.ename, mgr.ename 
FROM emp, emp mgr 
WHERE emp.mgr = mgr.empno(+) 


要 使 用 新 的 语法 指定 外 联接 ， 存 在 几 种 可 行 性 。 举 例 来 说 ， 下 面 的 两 个 查询 等 同 于 上 一 个 : 
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SELECT emp.ename, mgr.ename 
FROM emp LEFT JOIN emp mgr ON emp.mgr = mgr.empno 


SELECT emp.ename, mgr.ename 
FROM emp mgr RIGHT JOIN emp ON emp.mgr = mgr.empno 


下 面 的 查询 展示 ， 对 于 内 联接 ， 可 能 会 添加 OUTER 关 键 字 ， 以 显 式 指定 这 是 一 个 外 联接 : 


SELECT emp.ename, mgr.ename 
FROM emp LEFT OUTER JOIN emp mgr ON emp.mgr = mgr.empno 


此 外 ,使 用 新 的 联接 语法 ， 可 以 借助 于 完全 外 联接 ( full outer join ) 指定 返回 两 张 表 的 全 部 数据 。 
换 句 话说 ， 两 张 表 中 在 男 外 一 张 表 中 没有 匹配 记录 的 所 有 数据 都 要 保留 。 下 面 的 查询 是 一 个 例子 : 


SELECT mgr.ename AS manager, emp.ename AS subordinate 
FROM emp FULL OUTER JOIN emp mgr ON emp.mgr = mgr.empno 


男 一 种 可 能 性 是 指定 一 个 已 分 区 外 联接 ( partitioned outer join )。 注 意 : 此 处 分 区 的 意思 与 第 13 章 
中 讨论 的 对 象 物理 分 区 没有 任何 关系 。 相 反 ， 它 的 意思 是 数据 在 运行 时 被 分 成 多 个 子 集 。 其 思路 是 不 
在 两 张 表 之 间 执 行 外 联接 , 而 是 在 一 张 表 与 另外 一 张 表 的 子 集 之 间 执 行 。 举例 来 说 , 在 下 面 的 查询 中 ， 


emp 表 被 基于 job 列 分 成 多 个 子 集 。 然 后 每 个 子 集 与 dept 表 进行 外 联接 : 
SELECT dept.dname, count(emp.empno) 
FROM dept LEFT JOIN emp PARTITION BY (emp. jy ON emp.deptno = dept.deptno 


WHERE emp.job = “MANACER” 
GROUP BY dept.dname 


6. 半 联 接 

两 张 表 之 间 的 半 联 接 ( semi-join ) 会 在 另外 一 张 表 中 找到 匹配 的 记录 时 , 返回 当前 这 张 表 的 数据 。 
与 自 联接 相反 ,来 自 左 输入 的 数据 至 多 被 返回 一 次 。 此 外 ,来自 右 输入 的 数据 根本 不 会 被 返回 。 联 接 
条 件 是 通过 IN、EXISTS、ANY 或 50ME 编 写 的 。 下 面 的 查询 是 一 个 例子 : 

SELECT deptno, dname, loc 


FROM dept 
WHERE deptno IN (SELECT deptno FROM emp) 


SELECT deptno, dname, loc 
FROM dept 
WHERE EXISTS (SELECT deptno FROM emp WHERE emp.deptno = dept.deptno) 


SELECT deptno, dname, loc 
FROM dept 
WHERE deptno = ANY (SELECT deptno FROM emp) 


SELECT deptno, dname, loc 
FROM dept 
WHERE deptno = SOME (SELECT deptno FROM emp) 


7. 反 联 接 
反 联 接 (anti-join ) 是 一 种 特殊 类 型 的 半 联 接 ， 只 有 在 另外 一 张 表 中 没有 匹配 记录 的 那些 数据 会 
被 返回 。 联 接 条 件 通常 是 使 用 NOT IN 或 NOT EXISTS 编 写 的 。 下 面 的 两 个 查询 是 例子 : 
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SELECT deptno, dname, loc 
FROM dept 
WHERE deptno NOT IN (SELECT deptno FROM emp) 


SELECT deptno, dname, loc 
FROM dept 
WHERE NOT EXISTS (SELECT deptno FROM emp WHERE emp.deptno = dept.deptno) 


8. 横向 内 联 视 图 

横向 内 联 视 图 ( lateral inline view ) 是 一 个 内 联 视 图 ( inline view， 在 男 一 个 查询 的 FROM 子 句 中 指 
定 的 查询 ), 包含 着 指向 FROM 子 句 中 先 于 它 出 现 的 其 他 表 的 关联 条 件 。 从 12.1 版 本 开始 , 横 癌 内 联 视 图 
是 通过 LATERAL 关 键 字 来 支持 的 。 下 面 的 查询 展示 了 一 个 例子 : 


SELECT dname, ename 
FROM dept, LATERAL(SELECT * FROM emp WHERE dept.deptno = emp.deptno) 


注意 ， 如 果 缺 少 LATERAL 关键 字 ， 会 引发 以 下 错误 : 


SOL> SELECT dname, empno 
2 FROM dept, (SELECT * FROM emp WHERE dept.deptno = emp.deptno); 
FROM dept, (SELECT * FROM emp WHERE dept.deptno = emp.deptno) 
米 


ERROR at line 2: 
ORA-00904: "DEPT"."DEPTNO": invalid identifier 
对 于 外 联接 和 交叉 联接 ， 通 过 OUTER APPLY 和 CROSS APPLY 关 键 字 提供 了 类 似 的 功能 ， 


14.1.3 ”限制 条 件 与 联接 条 件 


为 选择 一 个 联接 方法 ， 理 解 限制 条 件 ( 也 称 为 过 滤 条 件 -) 与 联接 条 件 之 间 的 区 别 非常 重要 。 从 语 
法 的 角度 看 ， 仅 当 使 用 经 典 联接 语法 时 ， 这 两 者 才 会 造成 困惑 。 事 实 上 ， 使 用 经 典 联接 语法 ，WHERE 
子 句 同时 被 用 来 指定 限制 条 件 和 联接 条 件 。 使 用 新 的 联接 语法 ， 限 制 条 件 在 WHERE 子 句 中 指定 ， 而 联 
接 条 件 则 在 FROM 子 句 中 指定 。 下 面 的 伪 SQL 语 句 演示 了 此 语法 : 

SELECT <columns> 


FROM <table1> [OUTER] JOIN <table2> ON ( «join conditions> ) 
WHERE <restrictions> 


从 概念 的 角度 看 ， 一 条 包含 联接 条 件 和 限制 条 件 的 SQL 语句 以 下 面 的 方式 执行 。 

口 这 两 组 数据 基于 联接 条 件 联接 。 

口 限制 条 件 被 应 用 于 联接 返回 的 结果 集 。 

换 句 话说 ,在 联接 两 组 数据 的 时 候 , 一 个 联接 条 件 被 指定 以 避免 交叉 联接 。 它 并 不 打算 过 滤 掉 结 
果 集 。 反 而 ， 会 指定 一 个 限制 条 件 ， 以 过 滤 由 上 一 个 操作 ( 例如 ,一 个 联接 ) 返回 的 结果 集 。 举 例 来 
说 ， 下 面 的 查询 ， 联 接 条 件 是 emp.deptno = dept.deptno， 而 限制 条 件 是 dept.1loc = 'DALLAS': 

SELECT emp.ename 

FROM emp，dept 


WHERE emp.deptno = dept.deptno 
AND dept.loc = “DALLAS" 
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从 实现 的 角度 看 ， 查 询 优化 器 同时 利用 限制 条 件 和 联接 条 件 没什么 不 寻常 的 。 一 方面 ， 联 接 条 件 
可 能 被 用 于 过 滤 掉 数据 。 另 一 方面 ， 限 制 条 件 可 能 会 在 联接 条 件 之 前 被 评估 以 最 小 化 需要 联接 的 数据 
总 量 。 举 例 来 说 ， 上 面 的 查询 可 能 会 使 用 以 下 的 执行 计划 执行 。 注 意 dept.loc =“'DALLAS' 这 个 限制 条 
件 (操作 2 ) 是 如 何 早 于 emp.deptno = dept.deptno 这 个 联接 条 件 ( 操作 1 ) 被 应 用 的 : 


0 | SELECT STATEMENT | | 
1 | HASH JOIN | | 
* 2 | TABLE ACCESS FULL| DEPT | 
3 | TABLE ACCESS FULL| EMP | 


1 - access("EMp"."DEPTNO"="DEPT"."DEPTNO") 
2 - filter("DEPT"."LOC"="'DALLAS') 


14.2 ” 藤 套 循环 联接 


接 下 来 的 小 节 会 介绍 谱 套 循环 联接 (nested logp join ) 是 如 何 工作 的 。 我 会 描述 它们 的 普遍 行为 ， 
然后 会 给 出 几 个 两 表 联 接 和 四 表 联 接 的 例子 。 最 后 ， 我 会 介绍 一 些 优化 技巧 。 所 有 的 例子 都 来 自 
nested loops join.sql 这 个 脚本 。 

14.2.1 概念 


由 嵌 套 循环 联接 处 理 的 两 组 数据 称 作 外 循环 ( 也 称 作 驱动 行 源 ) 和 内 循环 。 外 循环 是 左 输入 ， 而 
内 循环 则 是 右 输入 。 如 图 14-6 所 列举 的 那样 ， 外 循环 执行 一 次 ， 内 循环 则 为 由 外 循环 返回 的 每 一 行 数 


据 都 执行 一 次 。 
行 加 执行 内 层 循环 


图 14-6 ”概览 由 府 套 循环 联接 执行 的 处 理 
内 套 循环 联接 拥有 的 具体 特征 如 下 所 示 。 
口 左 输入 ( 外 循环 ) 只 执行 一 次 。 右 输入 ( 内 循环 ) 可 能 会 执行 很 多 次 。 
口 它们 能 够 在 处 理 完 所 有 数据 之 前 就 返回 结果 集 的 第 一 行 。 


480 第 14 章 优化 联接 


口 它们 既 可 以 利用 索引 应 用 于 限制 条 件 上 ， 也 可 以 应 用 于 联接 条 件 上 。 
口 它们 支持 所 有 类 型 的 联接 。 


14.2.2 ”两 表 联 接 


下 面 是 一 个 处 理 两 表 之 间 的 舱 套 循环 联接 的 样 例 执行 计划 。 该 样 例 还 展示 如 何 通过 使 用 leading 
和 use_nl hint 强 制 执行 一 个 找 套 循环 联接 。 前 者 表明 表 被 访问 的 顺序 。 换 句 话 说 ， 它 指定 哪 张 表 是 在 
外 循环 (td1 ) 中 访问 以 及 哪 张 表 是 在 内 循环 (t2 ) 中 访问 。 后 者 指定 哪 种 联接 方法 用 于 联接 内 循环 返 
回 的 数据 和 t1 表 。 一 定 要 注意 ，use_nl hint 不 包含 对 表 t1 的 引用 : 


SELECT /*+ leading(t1 t2) use nl(t2) full(t1) full(t2) */ * 
FROM t1, t2 

WHERE t1.id = t2.t1 id 

AND t1i.n = 19 


0 | SELECT STATEMENT | | 
1 | NESTED LOOPS | | 
2 | TABLE ACCESS FULL| T1 | 
3 | TABLE ACCESS FULL| T2 | 


2 - filter("T1"."N"=19) 
3 ~ filter( TL". "TD"T2". wT TD 

如 第 10 章 中 所 述 ，NESTED LOOPS 操 作 属 于 关联 组 合 类 型 。 这 意味 着 第 一 个 子 操作 ( 外 循环 ) 控制 
着 第 二 个 子 操作 ( 内 循环 ) 的 执行 。 在 此 案例 中 ， 执 行 计划 的 处 理 过 程 可 以 总 结 成 以 下 这 样 。 

口 表 t1 中 的 所 有 数据 都 通过 一 次 全 表 扫 描 读 取 ， 接 下 来 应 用 了 n = 19 限 制 条 件 。 

口 表 t2 的 全 表 扫 描 执 行 的 次 数 与 上 一 步 中 返回 的 行 数 相同 。 

显然 ， 当 操作 2 ( TABLE ACCESS FULL ) 返回 超过 一 行 时 ， 上 面 的 执行 计划 不 是 高 效 的 ， 因 此 ， 
几乎 永远 不 会 被 查询 优化 器 选择 。 基 于 这 个 原因 ， 为 了 产生 这 个 特殊 的 例子 ， 有 必要 指定 两 个 访问 
hint〈full ) 来 强制 查询 优化 器 使 用 此 执行 计划 。 另 一 方面 ， 如 果 外 循环 返回 一 个 单独 的 行 且 内 循 
环 的 选择 率 很 弱 , 表 t2 的 全 表 扫 描 可 能 就 是 合理 的 。 为 了 证 实 , 我 们 为 表 t1 的 列 n 创 建 了 下 面 的 唯一 
索引 : 

CREATE UNIQUE INDEX t1 n ON tl (n) 

有 了 这 个 索引 ， 就 可 以 使 用 下 面 的 执行 计划 来 执行 前 面 的 查询 。 注 意 ， 这 一 次 只 有 一 个 控制 t2 表 
的 访问 路 径 的 hint 被 指定 。 其 他 的 hint 没 有 必要 ， 因 为 查询 优化 器 清楚 在 这 样 的 环境 下 构 套 循环 联接 是 
执行 此 查询 最 高 效 的 方式 。 事 实 上 ， 因 为 操作 3 ( INDEX UNIQUE SCAN ) 的 缘故 ， 可 以 确保 内 循环 仅 执 
行 一 次 : 

SELECT /*+ full(t2) */ * 

FROM t1, t2 


WHERE t1.id = t2.t1 id 
AND t1.n = 19 


14.2” 谱 套 循环 联接 481 


| Id | Operation | Name | 


0 | SELECT STATEMENT | 

1 | NESTED LOOPS | | 
2 | TABLE ACCESS BY INDEX ROWID| T1 | 
3 | INDEX UNIQUE SCAN | TEN 
4 | TABLE ACCESS FULL |T2 | 


3 - access("T1"."N"=19) 
4 = 位 十 和 DT 
就 像 在 上 一 小 节 中 讨论 过 的 那样 ， 如 果 内 循环 的 选择 性 很 强 ， 为 内 循环 使 用 索引 扫描 是 合理 的 。 
因为 嵌 套 循环 联接 是 一 个 关联 组 合 操作 ， 对 于 内 循环 来 说 甚至 可 能 利用 联接 条 件 来 实现 索引 扫描 。 举 
例 来 说 ， 在 下 面 的 执行 计划 中 ， 操 作 5 使 用 操作 3 返回 的 列 t1.id 的 值 进行 了 检索 : 


SELECT /*+ ordered use nl(t2) index(t1) index(t2) */ * 


FROM t1, t2 

WHERE t1.id = t2.t1 id 

AND t1.n = 19 

| Id | 0peration | Name | 
| 0 | SELECT STATEMENT | | 
| 1 | NESTED LOOPS | | 
| 2| TABLE ACCESS BY INDEX ROWID| T1 | 
|* 3 | INDEX UNIOUE SCAN | TIN 

| 4| TABLE ACCESS BY INDEX ROWID| T2 | 
|* 5 | INDEX RANGE SCAN | i | 


3 - access("T1"."N"=19) 
5 = access("T1"."ID"="T2"."T1 ID") 
总 之 ， 如 果 内 循环 被 执行 了 几 (或 很 多 ) 次 ， 只 有 假设 具有 强 选择 性 以 及 只 会 导致 很 少 的 逻辑 读 
的 访问 路 径 是 合理 的 。 


14.2.3 ”四 表 联 接 


下 面 的 执行 计划 是 一 个 典型 的 左 深 树 的 例子 , 使 用 艇 套 循 环 联接 实现 ( 图 示 请 参考 图 14-2 )。 注 意 
每 张 表 都 是 如 何 通过 索引 访问 的 。 这 个 例子 还 展示 了 如 何 通过 ordered 和 use_nl hint 来 强制 执行 拒 套 循 
环 联 接 。 前 者 指定 按照 表 在 FROM 子 句 中 出 现 的 相同 顺序 来 访问 它们 。 后 者 指定 哪 种 联接 方法 用 于 联接 
由 hint 引 用 的 表 和 第 一 张 表 或 上 一 个 联接 操作 的 结果 集 : 

SELECT /# ordered USe nl(t2 t3 t4) */ t1.*, Et2,*, :t3.*, tA4.* 

FROM t1, t2, t3, t4 

WHERE tl.id = t2.t1 id 


AND t2.id = t3.t2 id 
AND t3a.id = t4.t3 id 
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AND tl.n = 19 

| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
| 1| NESTED LOOPS | | 
| 2| NESTED LOOPS | | 
| 3| NESTED LOOPS | 
| 4| TABLE ACCESS BY INDEX ROWID| T1 | 
|# 5| INDEX RANGE SCAN | TLN | 
| 6| TABLE ACCESS BY INDEX ROWID| T2 | 
二] INDEX RANGE SCAN | Tz Tr iD | 
| 8 | TABLE ACCESS BY INDEX ROWID | T3 | 
|* 9| INDEX RANGE SCAN | T3_.T12 1D | 
| 10| TABLE ACCESS BY INDEX ROWID | T4 | 
|* 11 | INDEX RANGE SCAN | T4_T3_ID | 


5 - access("T1"."N"=19) 

7 3 Acess(" TL "ID"="T2 "TL ID"Y 
9 = ES 人 TD 
于 = access( T3 ID Te T3 ID") 


这 种 类 型 的 执行 计划 的 处 理 过 程 可 以 总 结 成 如 下 几 点 〈 该 描述 假设 没有 使 用 行 预 取 )。 

(1) 当 提取 第 一 行 ( 换 句 话 说， 不 是 在 查询 被 解析 或 执行 的 时 候 ) 时 ， 处 理 过 程 以 从 表 t1 中 获取 满 
足 t1.n = 19 限 制 条 件 的 第 一 行为 开始 。 

(2) 根据 在 表 t1 中 找到 的 数据 ， 检 索 表 t2。 注 意 ， 数 据 库 引擎 利用 t1.id = t2.t1 id 联接 条 件 访问 
表 t2。 事 实 上 ， 那 张 表 上 没有 应 用 任何 限制 条 件 。 只 有 第 一 条 满足 联接 条 件 的 记录 被 返回 给 父 操作 。 

(G3) 根据 在 表 t2 中 找到 的 数据 , 检索 t3 表 。 在 这 个 情况 中 也 一 样 ， 数据 库 引擎 利用 联接 条 件 t2.id = 
t3.t2_id 来 访问 表 t3。 只 有 第 一 条 满足 联接 条 件 的 记录 被 返回 给 父 操作 。 

(4) 根据 在 表 t3 中 找到 的 数据 , 检索 t4 表 , 这 里 也 是 一 样 , 数据 库 引 擎 利用 联接 条 件 t3.id =t4.t3_id 
来 访问 表 t4。 第 一 条 满足 联接 条 件 的 记录 被 立即 返回 给 客户 端 。 

(5) 当 提取 随后 的 记录 后 ， 会 执行 与 第 一 次 提取 时 一 样 的 动作 。 显 然 ， 处 理 过 程 从 紧邻 上 一 次 匹 
配 的 位 置 重新 开始 (可 以 是 匹配 表 t4 的 第 二 条 记录 ， 如 果 存 在 的 话 )， 这 里 有 必要 强调 一 下 ,一旦 找 
到 第 一 条 满足 要 求 的 记录 ， 就 会 尽快 返回 该 记录 。 没 有 必要 在 返回 第 一 条 数据 前 完全 执行 联接 。 


14.2.4 缓冲 区 缓存 预 取 


基本 上 ,每 条 访问 路 径 ， 除 了 全 扫描 ， 都 会 导致 缓存 未 命中 事件 中 的 单 块 物理 读 。 对 于 典 套 循环 
联接 ,尤其 是 需要 处 理 大 量 数 据 的 时 候 ， 这 些 单 块 物理 读 的 效率 可 能 非常 低下 。 事 实 上 ， 对 于 内 套 循 
环 联接 来 说 ， 伴 随 很 多 的 单 块 物理 读 来 访问 数据 块 也 没有 什么 不 寻常 的 。 

为 了 改进 艇 套 循环 联接 的 效率 ， 数据库 引 擎 能 够 利用 以 多 块 物 理 读 代 蔡 单 块 物理 读 的 优化 技术 
有 三 种 特性 使 用 这 样 的 方法 : 表 预 取 ( table prefetching )、 批 处 理 ( batching ) 以 及 缓冲 区 缓存 预 热 ( buffer 
cache prewarm )。 前 两 个 与 本 节 呈 现 的 执行 计划 有 关 ; 最 后 一 个 只 会 在 实例 重启 后 因为 租 套 循环 联接 
而 短暂 出 现 。 注 意 这 些 优 化 技术 在 访问 表 和 索引 的 时 候 都 会 执行 。 
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14.2.2 节 展示 了 一 个 具有 以 下 形状 的 执行 计划 ， 该 执行 计划 基于 内 套 循环 联接 : 


| Id | 0peration | Name | 
| 0 | SELECT STATENMENT | | 
| 1 | NESTED LOOPS | | 
| | TABLE ACCESS BY INDEX ROWID| T1 | 
|* 3 | INDEX UNIOUE SCAN | TLN | 
| 4 | TABLE ACCESS BY INDEX ROWID| T2 | 
be INDEX RANGE SCAN | T2174 和 | 


3 - access("T1"."N"=19) 
5 = Access("T1" "ID"="T2"." TL TOD") 


在 实践 中 ， 对 于 本 书 涵盖 的 Oracle 数 据 库 版 本 来 说 ， 这 种 类 型 的 执行 计划 只 用 于 基于 索引 的 唯一 
扫描 ( 此 处 t1_n 索 引 是 唯一 的 ) 的 外 循环 或 内 循环 ,我 们 来 看 一 下 如 果 列 n 上 的 t1_n 索 引 按 以 下 方式 ( 非 
唯一 ) 定义 会 发 生 什 么 : 

CREATE INDEX t1_n ON t1 (n) 

有 了 这 个 索引 ， 就 会 使 用 以 下 执行 计划 。 注 意 表 t2 上 的 rowid 访 问 的 不 同位 置 。 在 上 一 个 计划 中 ， 
它 是 操作 4， 而 在 接 下 来 的 这 个 计划 中 ， 它 是 操作 1。 非常 独特 的 是 ，rowid 访 问 〈 操作 1 ) 的 子 操作 是 
储 套 循环 联接 操作 2 )。 即 使 从 功能 的 角度 来 看 这 两 个 执行 计划 是 等 效 的 ,但 数据 库 引 擎 使 用 具有 以 
下 形状 的 执行 计划 以 利用 表 预 取 : 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
| 1| TABLE ACCESS BY INDEX ROWID | T2 | 
| 2| NESTED LOOPS | | 
| 3| TABLE ACCESS BY INDEX ROWID| T1 | 
I* 4| INDEX RANGE SCAN | TiN | 
|* 5 | INDEX RANGE SCAN | Tz TL TD | 


4 - access("T1"."N"=19) 
5 - access("T1"。 ID"="T2"。T1 ID") 


从 11.1 版 本 开始 ， 可 以 通过 n1j prefetch 和 no_n1j_prefetch hint 来 控制 上 面 执行 计划 的 使 用 。 
从 11.1 版 本 开始 ， 为 进一步 优化 嵌 套 循环 联接 ， 表 预 取 被 批 处 理 所 取代 。 结 果 ， 应 该 可 以 观察 到 
下 面 的 执行 计划 而 非 上 面 的 那个 : 


| SELECT STATEMENT | | 
| NESTED LOOPS | | 
| NESTED LOOPS | 
| TABLE ACCESS BY INDEX ROWID| T1 | 
| INDEX RANGE SCAN | TLN | 
| INDEX RANGE SCAN | 入 入 元 
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| 6| TABLE ACCESS BY INDEX ROWID | T2 


4 - access("T1"."N"=19) 
5 - access("T1"."ID"="T2"."T1 ID") 
注意 ， 尽 管 查询 总 是 相同 的 ( 就 是 说 ， 两 表 联接 )， 但 是 该 执行 计划 却 包含 两 个 嵌 套 循环 联接 ! 
要 控制 批 处 理 ， 可 以 使 用 n1j_batching 和 no_n1j_batching hint。 
查看 执行 计划 并 不 能 告诉 你 数据 库 引 擎 是 否 使 用 了 表 预 取 或 批 处 理 。 事 实 是 ， 尽 管 是 查询 优 
化 器 生成 一 个 可 以 利用 表 预 取 或 批 处 理 的 执行 计划 ,但 却 是 执行 引擎 决定 使 用 这 个 计划 是 否 合 理 
了 解 一 项 优化 技术 是 否 被 使 用 的 唯一 方式 是 查看 服务 进程 执行 的 物理 读 ， 尤 其 是 与 其 有 关 的 等 待 
事件 。 
口 db file sequential read 事 件 与 单 块 物理 读 有 关 。 因 此 ， 如 果 此 事件 出 现 ， 那么 要 么 是 没有 使 
用 优化 技术 ， 要 么 是 不 需要 优化 技术 ( 例如 ， 因 为 所 需 的 数据 块 已 经 在 缓冲 区 缓存 中 )。 
口 db file scattered read 和 db file parallel read 事 件 与 多 块 物理 读 有 关 。 这 两 个 事件 之 间 的 
不 同 在 于 前 者 是 用 于 相 邻 数据 块 的 物理 读 ， 而 后 者 是 用 于 非 相 邻 块 的 物理 读 。 因 此 ， 如 有 果 它 
们 其 中 的 一 个 出 现在 rowid 访 问 或 索引 范围 扫描 中 ,说明 没有 使 用 任何 优化 技术 ， 


14.3 合并 联接 


接 下 来 的 小 节 描述 合并 联接 ( merge join， 也 称 作 排 序 合 并 联接 ，sort-merge join ) 是 如 何 工作 的 ， 
我 会 描述 它们 的 共性 行为 ， 并 给 出 一 些 两 表 联 接 和 四 表 联 接 的 例子 作为 开头 。 最 后 ， 我 会 描述 在 处 理 
期 间 使 用 的 工作 区 。 所 有 的 例子 都 来 自 merge_join.sql 脚 本 。 


14.3.1 概念 


取决 于 SQL 语句 和 物理 数据 库 设计 ， 在 执行 合并 联接 时 数据 库 引 擎 可 以 在 多 种 方式 之 间 进 行 选 
择 。 在 一 般 情况 下 ， 两 组 数据 都 会 根据 联接 条 件 的 列 进行 读 取 和 排序 。 一 旦 这 些 操 作 执 行 完 毕 ， 包 含 
在 两 个 工作 区 中 的 数据 就 会 被 合并 ， 如 图 14-7 所 示 。 

合并 联接 拥有 的 具体 特征 如 下 所 示 。 

口 左 输入 仅 被 执行 一 次 。 

口 右 输入 至 多 被 执行 一 次 。 如 果 左 输入 不 返回 任何 数据 ， 右 输入 则 根本 不 会 被 执行 。 

口 除了 执行 了 笛 卡 儿 积 的 情况 ， 两 个 输入 返回 的 数据 必须 被 根据 联接 条 件 的 列 进行 排序 。 

口 当 数据 进行 排序 后 ， 在 返回 结果 集 的 第 一 行 数据 之 前 ， 必 须 完 整 读 取 并 排序 两 个 输入 。 

口 支持 所 有 类 型 的 联接 。 

合并 联接 的 使 用 并 不 是 很 频繁 。 原因 是 , 在 大 多 数 的 情况 下 , 无 论 是 典 套 循环 联接 还 是 散 列 联接 ， 
都 执行 得 比 合并 联接 要 更 好 。 
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i 工作 区 2 
Ee 
4 
产 、 天 
/ 


图 14-7 合并 联接 执行 的 处 理 过 程 概览 


14.3.2 ”两 表 联 接 

下 面 是 一 个 简单 的 处 理 两 表 之 间 合 并 联接 的 执行 计划 。 该 例子 还 展示 了 如 何 通 过 使 用 ordered 和 
use_merge 这 两 个 hint 来 强制 执行 合并 联接 : 

SELECT /*+ ordered use merge(t2) */ * 


FROM t1, t2 
WHERE t1,id = t2.t1 id 
AND ti.n = 19 
Id Operation | Name | 
0 | SELECT STATEMENT | 
Yl MERGE JOIN | | 
2 SORT JOIN | | 
3 TABLE ACCESS FULL| T1 | 
只 : 进 SORT JOIN | | 
5 TABLE ACCESS FULL| T2 | 


3 = lter("Ti".N"=19) 
4 = aceess( "Ti"."I0"="T2"."TY ID") 
ile "Te "ID"=" TT Wm") 
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如 第 10 章 中 所 描述 的 ，MERGE JOIN 操作 是 非 关 联 组 合 的 类 型 。 这 意味 着 两 个 子 操作 至 多 被 处 理 一 
次 并 且 互 相 独 立 。 假 设 两 个 输入 都 返回 数据 ， 上 面 的 执行 计划 的 处 理 过 程 可 以 总 结 为 以 下 几 点 。 
口 表 t1 中 的 所 有 数据 都 是 通过 全 扫描 读 取 的 ， 应 用 了 n = 19 这 个 限制 条 件 ， 而 且 结果 数据 根据 用 
作 联 接 条 件 的 列 ( id ) 进行 了 排序 。 
口 表 t2 中 的 所 有 数据 都 是 通过 全 扫描 读 取 的 ， 并 根据 用 作 联 接 条 件 的 列 (ti id ) 进行 了 排序 。 
口 这 两 组 数据 被 联接 到 一 起 ， 然 后 返回 了 结果 数据 。 注 意 联接 本 身 简单 明了 ， 因 为 这 两 组 数据 
是 根据 相同 的 值 排序 的 ( 用 在 联接 条 件 中 的 列 )。 
有 趣 的 是 ,我 们 留意 到 在 上 面 的 执行 计划 中 ， 联 接 条 件 是 通过 右 输 入 的 SORT JOIN 操作 应 用 的 ， 而 
不 是 通过 也 许 你 会 预期 的 MERGE JOIN 操作 应 用 的 。 这 是 因为 对 于 每 一 行 由 左 输入 返回 的 数据 ，MERGE 
JOIN 操作 都 会 访问 与 右 输 入 有 关 的 内 存 结构 来 检查 是 否 有 满足 联接 条 件 的 记录 存在 。 


注意 ”SORT JOIN 操作 与 SORT ORDER BY 操作 之 间 的 关键 区 别 是 前 者 总 是 执行 二 进 制 排序 ， 而 后 者 ， 取 
决 于 NLS 配 置 ， 既 可 以 执行 二 进 制 排序 也 可 以 执行 语言 上 的 排序 。 


MERGE JOIN 操作 ( 对 于 其 他 无 关联 组 合 操作 也 类 似 ) 最 主要 的 限制 是 它 没有 能 力 通过 在 联接 条 件 
上 应 用 索引 来 获 益 。 换 名 话说 , 仅 可 以 在 对 输入 排序 之 前 将 索引 用 作 一 条 访问 路 径 来 验证 限制 条 件 ( 如 
果 已 指定 )。 因 此 ， 为 了 选择 访问 路 径 ， 你 不 得 不 为 两 张 表 应 用 在 第 13 章 中 讨论 的 方法 。 举 个 例子 ， 
如 果 n=19 这 个 限制 条 件 提 供 强 选择 性 ， 在 此 列 上 创建 索引 并 应 用 ， 效 果 会 很 明显 : 

CREATE INDEX t1 n ON tl (n) 

有 了 这 个 索引 后 ， 可 能 会 使 用 以 下 执行 计划 。 你 应 该 注意 到 ， 不 再 通过 全 表 扫描 访问 表 t1 了 : 


Id Operation | Name 
0 | SELECT STATEMENT | 
1 | MERGE JOIN | 
2 SORT JOIN | | 
3 TABLE ACCESS BY INDEX ROWID| T1 | 
* 4 INDEX RANGE SCAN | TiN 
* 5 SORT JOIN | 
6 TABLE ACCESS FULL 本 


4 - access("T1"."N"=19) 
5 - access("T1"."ID"="T2"."T1 ID") 
filter("T1". "ID"="T2"."T1_ID") 

要 执行 合并 联接 ， 可 能 会 有 不 可 忽视 的 资源 总 量 消耗 在 排序 上 。 为 改进 性 能 ， 只 要 能 够 节省 资 
源 ， 查 询 优 化 器 无 论 何 时 都 会 避免 执行 排序 操作 。 但 只 有 当 数 据 已 根据 用 作 联 接 条 件 的 列 进行 了 排 
序 时 这 才 可 行 。 这 种 行为 会 在 两 种 情况 下 出 现 。 第 一 种 是 索引 范围 扫描 利用 在 作为 联接 条 件 使 用 的 
列 上 创建 的 索引 时 。 第 二 种 是 在 合并 排序 的 上 一 步 ( 例如 ， 另 一 个 排序 合并 ) 中 已 经 将 数据 以 正确 
的 顺序 进行 了 排序 时 。 举 例 来 说 , 在 下 面 的 执行 计划 中 , 注意 表 t1 是 如 何 通过 t1_pk 索 引 ( 也 就 是 在 
用 作 联 接 条 件 的 id 列 上 创建 的 索引 ) 进 行 访 问 的 。 因 此 , 对 于 左 输入 ,就 避免 了 排序 操作 ( SORT JOIN ): 
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| Id | Operation | Name | 
| 0 | SELECT STATEMENT | 

| 1 | MERGE JOIN | | 
|* | TABLE ACCESS BY INDEX ROWID| T1 | 
| 3| INDEX FULL SCAN | Ti_Pk | 
|* 4 | SORT JOIN | | 
| 5| TABLE ACCESS FULL 1 六 | 


2 - filter("T1"."N"=19) 
4 EE TL TT Ty OY 
filter("T1"."ID"="T2"."T1_ID") 

一 个 关于 类 似 上 面 这 样 的 执行 计划 的 重要 警告 是 ， 因 为 对 于 左 输入 来 讲 没有 发 生 任何 排序 ， 所 以 
没有 工作 区 与 其 进行 关联 。 结 果 就 是 ， 当 右 输 入 执行 时 ,没有 空间 来 存储 来 自 左 输入 的 结果 数据 。 上 
面 的 执行 计划 可 以 总 结 为 以 下 几 步 。 

(1) 第 一 批 数据 通过 t1 pk 索引 从 t1 表 中 抽取 出 来 。 一 定 要 理解 第 一 批 数据 仅 在 结果 集 很 小 的 时 候 
才 会 包含 所 有 的 数据 。 记 住 ， 此 时 没有 工作 区 来 临时 存储 很 多 数据 。 

(2) 假设 上 一 步 中 返回 了 一 些 数据 ，t2 表 中 的 所 有 数据 都 通过 全 表 扫 描 读 取出 来 ， 根 据 作 为 联接 
条 件 使 用 的 列 进行 排序 ， 并 且 在 工作 区 中 排序 时 ， 可 能 会 将 临时 数据 溢出 到 磁盘 上 。 

(3) 将 两 组 数据 联接 到 一 起 ， 然 后 返回 结果 数据 。 当 第 一 批 抽 取 自 左 输入 的 数据 已 被 完全 处 理 时 ， 
继续 从 t1 表 抽取 更 多 的 数据 ， 如 果 有 必要 ， 则 与 右 输 入 已 经 呈现 在 工作 区 中 的 数据 进行 联接 。 

如 上 面 的 执行 计划 中 所 示 ， 有 可 能 避免 与 左 输入 相关 的 排序 。 但 是 ， 相 同 的 情况 却 不 适用 于 右 输 
入 。 为 解释 原因 ， 下 面 的 例子 展示 在 执行 与 以 前 一 样 的 查询 时 让 查询 优化 器 选择 执行 计划 ， 但 是 这 一 
次 通过 leading 这 个 hint 指 定 , 使 得 表 t2 必 须 在 左 输入 中 进行 访问 。 注 意 ， 尽 管 右 输入 的 访问 路 径 按 正 
确 的 顺序 返回 数据 ,但 是 数据 还 是 必须 经 历 一 次 SORT JOIN 操作 (4): 

SELECT /*+ leading(t2 t1) use merge(t1) index(t1 t1 pk) */ * 

FROM t1, t2 


WHERE t1.id = t2.t1 id 
AND t1.n = 19 


0 | SELECT STATEMENT | 
1 | MERGE JOIN | 
2 | SORT JOIN | 
3 TABLE ACCESS FULL 位 | 
4 | SORT JOIN | 
5 TABLE ACCESS BY INDEX ROWID| T1 | 
6 INDEX FULL SCAN TL_PK | 


= etesst" TL, "TD eT, "10 
filter("TL". "ID"s"T2". "TL ID") 
5 - filter("T1"."N"=19) 


需要 该 SORT JOIN 操作 的 原因 是 MERGE JOIN 操 作 需 要 访问 与 右 输入 关联 的 内 存 结构 ， 以 便 检查 是 否 
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有 满足 联接 条 件 的 数据 存在 。 而 这 个 访问 必须 在 这 样 一 个 内 存 结构 中 执行 ， 它 不 仅 包含 按 指定 顺序 存 
储 的 数据 ， 而 且 还 要 允许 基于 联接 条 件 执行 高 效 的 检索 。 

基于 合并 联接 的 笛 卡 儿 积 是 按照 不 同方 式 执 行 的 。 对 比 本 节 描 述 的 所 有 其 他 案例 ,应 用 于 它们 的 
主要 优化 是 数据 不 需要 进行 排序 。 原 因 很 简单 : 没有 联接 条 件 存 在 ， 因 此 不 可 能 根据 不 存在 的 联接 条 
件 中 引用 的 列 对 数据 进行 排序 。 因 此 ， 与 用 于 获取 数据 的 访问 路 径 无 关 ， 不 需要 SORT JOIN 操作 。 对 于 
右 输入 , 不 管 怎样 还 是 有 必要 在 一 个 内 存 结构 中 存储 数据 。 出 于 这 个 目的 , 会 使 用 BUFFER SORT 操 作 ( 不 
要 看 它 的 名 称 ， 它 不 会 对 数据 进行 排序 )。 下面 的 例子 演示 这 样 的 一 种 情况 : 


SELECT /*+ Ordered use merge(t2) */ * 
FROM t1, t2 


| 0 | SELECT STATEMENT | | 
| 1| MERGE JOIN CARTESIAN| | 
| 2| TABLEACCESS FULL |T1 | 
| 3| BUFFER SORT | | 
| 4| TABLE ACCESS FULL | T2 | 


14.3.3 ”四 表 联 接 


下 面 的 执行 计划 是 一 个 典型 的 通过 合并 联接 实现 左 深 树 ( 图 示 请 参见 图 14-2 ) 的 例子 。 该 例子 还 
展示 如 何 依靠 leading 和 use_merge 这 两 个 hint 来 强制 执行 合并 联接 。 注意 , leading 这 个 hint 支 持 多 张 表 : 


SELECT /*+ leading(t1 t2 t3 t4) use merge(t2 t3 t4) */ t1.*, t2.*, t3.*, t4.* 
FROM t1, t2, t3, t4 

WHERE t1.id = t2.t1 id 

AND t2.id = t3.t2 id 

AND t3.id = t4.t3_id 

AND t1.n = 19 


| Id | Operation | Name | 
0 | SELECT STATEMENT 
1 | MERGE JOIN 

2 SORT JOIN 

3 | MERGE JOIN 
4 | SORT JOIN 
5 | MERGE JOIN 
6 

六 

8 

9 

0 


| 

| 

| 

| 

| 

| 

SORT JOIN 

TABLE ACCESS FULL| T1 | 

SORT JOIN 

TABLE ACCESS FULL| T2 | 

SORT JOIN | 

11 TABLE ACCESS FULL | T3 | 
+ 12 | SORT JOIN 

13 | TABLE ACCESS FULL |T4 | 
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7 = filter "Ts NS 
8 = dc6058 TI" ID "12" Th 1D") 
filter( "Ta" 1D" "TT 1D*) 
10 = actess("T2"."1D"="T3"."T2 
Filter("T2". ODAS Ta AT2 ID" 
12 = access("T3"."ID"="T4"."T3, ID ) 
flter("T" ID"e" TA" "Ta ID") 
该 处 理 过 程 与 上 一 小 节 中 讨论 过 的 两 表 联接 没有 什么 本 质 区 别 。 然 而 ， 有 必要 强调 的 是 ,被 排序 
多 次 是 因为 每 个 联接 条 件 都 基于 不 同 的 列 。 举 例 来 说 ， 来自 表 t1 和 表 t2 之 间 的 联接 的 数据 结果 ， 是 根 
据 表 t1 的 id 列 来 排序 的 ， 操 作 4 会 根据 表 t2 的 id 列 再 次 对 其 进行 排序 。 同 样 的 事情 也 发 生 在 由 操作 3 返 
回 的 数据 上 。 事 实 上 ， 它 必须 根据 表 t3 的 id 列 进行 排序 。 总 之 ,为 处 理 这 种 类 型 的 执行 计划 ， 必 须 执 
行 六 次 排序 ， 而 且 它 们 必须 全 部 在 能 够 返回 任何 一 行 数据 之 前 执行 。 


14.3.4 工作 区 


为 了 处 理 合并 联接 ,最 多 有 两 个 内 存 中 的 工作 区 用 于 排序 数据 。 如 果 一 个 排序 被 完全 在 内 存 中 处 
理 ， 就 将 其 称 为 内 存 中 排序 (in-memory sort )。 如 果 一 个 排序 需要 将 临时 数据 溢出 到 磁盘 上 ， 就 将 其 
称 为 磁盘 上 排序 ( on-disk sort )。 从 性 能 的 角度 看 ， 内 存 中 排序 显然 比 磁盘 上 排序 要 更 快 。 下 面 会 讨论 
这 两 种 类 型 的 排序 如 何 工作 。 我 还 会 讨论 ， 如 何 根据 dbms_xplan 包 的 输出 ， 识 别 哪 一 种 排序 用 于 处 理 
一 条 SQL 语句 了 。 

我 在 第 9 章 讨论 过 工作 区 配置 (设置 大 小 )。 正 如 你 可 能 从 那 一 章 回想 起 来 的 那样 ， 有 两 种 设置 大 
小 的 方法 。 具 体 使 用 哪 一 种 取决 于 workarea_size _ policy 初始 化 参数 的 取 值 。 这 两 种 方法 如 下 所 示 。 

口 auto: 数据 库 引 擎 自动 调整 工作 区 的 大 小 。 一 个 实例 专 有 的 PGA 总 量 由 pga_aggregate target 

初始 化 参数 控制 ， 或 者 从 11.1 版 本 开始 ， 由 memory_target 初 始 化 参数 控制 。 

口 manual : sort area size 初始化 参数 限制 一 个 单独 的 工作 区 的 大 小 。 此 外 ， 

sort area retained size 初始 化 参数 控制 当 排序 完成 时 如 何 释放 PGA。 


1. 内 存 中 排序 

内 存 中 排序 的 处 理 过 程 直 截 了 当 。 将 数据 加 载 到 工作 区 后 , 排序 就 发 生 了 。 有 一 点 值得 强调 的 是 ， 
必须 将 所 有 数据 都 加 载 到 工作 区 中 ， 而 不 仅仅 是 作为 联接 条 件 引用 的 列 。 因 此 ， 为 避免 浪费 大 量 的 内 
存 ，SELECT 子 句 中 应 该 只 引用 真正 有 必要 的 列 。 为 证 实 这 一 点 ， 我 们 来 看 两 个 基于 上 一 节 中 讨论 的 四 
表 联接 的 例子 。 

在 下 面 的 例子 中 ， 所 有 表 中 的 所 有 列 都 在 SELECT 子 句 中 引用 了 。 在 执行 计划 中 ，OMem 和 Used-Mem 
列 提 供 关 于 工作 区 的 信息 。 前 者 是 为 内 存 中 排序 估算 的 内 存 总 量 。 后 者 是 在 执行 期 间 由 操作 使 用 的 真 
实 内 存 总 量 。 括 号 中 间 的 值 (也 就 是 o ) 意味 着 排序 是 完全 在 内 存 中 进行 的 : 

SELECT t1.*, t2.*+,t3.*, 二 4 

FROM t1, t2, t3, t4 

WHERE t1.id = t2.t1 id 

AND t2.id = t3.t2 id 


AND t3.id = t4.t3 id 
AND t1.n = 19 
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| Id Operation | Name | OMem | Used-Mem | 
| 0 | SELECT STATEMENT | | | | 
| 1| MERGE JOIN | | | | 
| 2 | SoRT JOIN | | 34816 |30720 (0)| 
| 3| MERGE JOIN | | | | 
| 4 SORT JOIN | | 5120 | 4096 (0)| 
| $3 MERGE JOIN | | | | 
| 6| SORT JOIN | | 3072 | 2048 (0)| 
|* 了 TABLE ACCESS FULL| T1 | | | 
| 总 SORT JOIN | | 21504 |18432 (0)| 
| 9 TABLE ACCESS FULL| T2 | | 

| SORT JOIN | | 160Kk| 142K (0)| 
| TABLE ACCESS FULL | T3 | | | 
|* 12 | SORT JOIN | | 1045K| 928K (0)| 
| 13 | TABLE ACCESS FULL [| | | 


7 - filter("T1"."N"=19) 
8 ~ Cease "TL. "TD "TT Toy 
Fr( TID aT. "Td TD") 
0 a access("T2" TDKEST32eT2 TD ) 
Flter( "T2103 TZ LD 
12 - access("T3"."ID"="T4"."T3_ID") 
filter("T3"."ID"="T4"."T3_ID") 


在 下 面 的 例子 中 ，SELECT 子 句 中 引用 的 列 中 只 有 一 个 没有 被 NHERE 子 句 引 用 (t4.id )。 有 一 点 很 重 
要 ， 就 是 除了 操作 6， 所 有 其 他 操作 都 使 用 了 更 小 的 工作 区 ， 而 且 这 还 是 在 两 个 案例 中 执行 计划 都 是 
相同 的 情况 下 。 还 要 注意 查询 优化 器 的 估算 ( 列 Omem ) 考虑 到 了 这 个 不 同 点 : 


SELECT t1.id, t2.id, t3.id, t4.id 
FROM t1, t2, t3, t4 

WHERE t1.id = t2.t1 id 

AND t2.id = t3.t2 id 

AND t3.id = t4.t3 id 


AND t1.n = 19 

| Id | Operation | Name | OMem | Used-Mem | 
| 0 | SELECT STATEMENT | | | | 
| 1 | MERGE JOIN | | | | 
| 2| SoRT JOIN | | 14336 |12288 (0)| 
| 3| MERGE JOIN | | | | 
| 过 SORT JOIN | | 3072 | 2048 (0)| 
| 每 MERGE JOIN | | | | 
| 志 | SORT JOIN | | 3072 | 2048 (0)| 
a | TABLE ACCESS FULL| T1 | | 

| SORT JOIN | | 16384 |14336 (0)| 
| 9 | TABLE ACCESS FULL| T2 | | 

|* 0 | SORT JOIN | | 106Kk|96256 (0)| 
| 潭 | TABLE ACCESS FULL | T3 | | | 
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|* 12 | SORT JOIN | | 407K| 361K (0)| 
I 带 . | TABLE ACCESS FULL 【大 汪 | | 


7 - filter("T1"."N"=19) 

8 = gccesst Ti DT 全 [和 TD) 
filtert"T1", "ID"<"T2™, Tt 1D") 

10 - access("T2"."ID"="T3"."T2 ID") 
filter("T2"."ID"="T3"."T2 ID") 

42 = aceess( TT3","ID"="T4","T3 1D") 
filter("T3"."ID"="T4". "T3_1D") 


2. 磁盘 上 排序 

当 一 个 工作 区 太 小 而 不 能 包含 所 有 数据 时 ， 数 据 库 引 擎 会 分 多 步 处 理 排序 。 这 些 步 骤 在 下 面 的 列 
表 中 详 述 。 显 然 ， 实 际 的 步骤 数量 不 仅 依赖 于 数据 总 量 ， 而 且 还 依赖 于 工作 区 的 大 小 。 

(1) 从 表 中 读 取 数据 并 存储 到 工作 区 中 。 当 对 其 排序 时 ， 一 个 根据 排序 标准 组 织 数据 的 结构 被 构 
建 出 来 。 在 本 例 中 ， 数 据 是 根据 id 列 进行 排序 的 。 这 是 图 14-8 中 的 第 1 步 。 


表 


=*_ ,QWw8'@ Tz$$>T\XINfH\ &5Sxhx1<,<jfigco72:P F]3QTW 
16 16 |w:3p~&t.3p-|A}S#0>*{wO{0|I>&yoh; #cGg~8F73[8zvg", 
20 20 /hscvqFU~-GG=*'d:pBHs@4am ly|spPDAqI6j (OiL9 U i/o. 
v&q)jM!:T_syoI8K%{<-~//Oyx3jceoqH *)3E&Avfrmlim'; ., 


3“n/IT6tIRHAS9URrkMs'&NopnP"COr7KwE4>t…M:<@je,iz,ok 
19 19 hjvsCc?9txeT4]kpPd)JG7Tn4z/.&o6z1.QCDQPN\XpbjxSt~k6im1 
12 12 E(%19qz0[iLmyowButwa/T<NPo1z7U$s]k&$qN<cOxv/A{d5A#B 
-r472prZ)%LGmsB/7ZQ'i5X1[Y1zAm >eDj*6'x}fTn(0c-}g+ 
Yg08-uUdQwxV]]J3tqE)}<]JCRf5r'n2wnT+*gv1dTNA>]bz-&1Bx 


ll1 11 n64C&KzymK9NhnL@Ox/g \ 

15 15 v&q)jM!:T_syor8K%{<-~ 八 
16 -16 |w:3p~&t.3p-|A}S#0>*{w \ 
18 18 =*_,G@w8'Q Tz$$>T\xINfH\ 
20 20 /hscvqFu~-GG=*'d:pBHs@ / 


临时 表 空 间 


CC 临 H 表 空间 > 2 


排序 运行 批 次 1 


图 14-8 ”磁盘 上 排序 ， 排 序 运 行 批 次 1 
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(2) 填 满 工作 区 后 ， 它 的 部 分 内 容 溢出 到 用 户 的 临时 表 空 间 中 的 一 个 临时 段 中 。 这 种 类 型 的 数据 
批 次 称 作 排序 运行 批 次 。 注意， 所 有 数据 不 仅 存 储 在 工作 区 中 ， 而 且 还 存储 在 临时 段 中 。 这 是 图 14-8 
中 的 第 2 步 。 

(3) 既然 数据 已 经 溢出 到 临时 段 中 ， 在 工作 区 中 就 有 了 一 些 空闲 空间 。 因 此 就 可 以 继续 在 工作 区 
中 读 取 并 排序 输入 的 数据 。 这 是 图 14-9 中 的 第 3 步 。 


表 


=*_,@w8'@ Tz$$>T\XINfH\ &5xhx1<,<j{figco72:P F]3@TW 
16 16 |w:3p~8&t.3p-|A}S#o>*{wO{0|I>&yoh; #cGg~8F73[8zvg", 
20 20 /hscvqFU~-GG=*'d:pBHs@4am ly|spPDAqI6j (OiL9 u i/o. 
VB) IM! :T_Ssyor8K%{<-~//Oyx3jCeoqH *)3E&A\v{rmlm: .， 


“Nn/I6t!HHAS9URrkMs '&Nopnp"cOr/KwE4>t  'M: <@}e, iz ,ok 
19 19 hjvS5c?9txeT4]kPd)G/ nd4z/ .8&oQ@z1 .QCDQAP\%pbjx$t~k6im] 
12 12 E(%lqz0[iLmyowButwa/T<NPO1lz7U$s]k&$q\<cOXv/A{d5A#B 
.r472prz)%L@msB/7Z@'i5%1[Y1zAm >eDjs*6'xjfrn(Oc-}9+ 


12 12 EC(%1qzO[iLmyowButwa/ \ 
13 13 ‘n/I6t!HHAS9URrkMs '&N 和 
14 14 .r4?2prZ)X%LEmsB/7ZQ@'i5% \ 
17 17 *$08-udQwxv]I3tqE)}<)( 
19 19 hjv5c?9txeT4]kPd)G/1n4z/ 


临时 表 空间 


、 ， “排序 运行 批 次 2 
、 “排序 运行 批 次 ! 


一 
图 14-9 ”磁盘 上 排序 ， 排 序 运行 批 次 2 


(4) 再 次 填 满 工作 区 后 ， 将 男 一 个 排序 运行 批 次 存储 到 临时 段 中 。 这 是 图 14-9 中 的 第 4 步 。 

(5) 对 所 有 数据 进行 排序 并 存储 到 临时 段 中 后 ， 就 该 合并 它 了。 合并 阶段 是 必要 的 ， 因 为 每 个 排 
序 运 行 批 次 都 是 独立 于 彼此 进行 排序 的 。 要 执行 合并 ， 从 每 个 排序 运行 批 次 中 读 取 回 一 些 数据 到 工作 
区 中 ， 从 每 个 排序 运行 批 次 的 头 部 开始 。 举 个 例子 ，id 等 于 11 的 记录 存储 在 排序 运行 批 次 1 中 ， 而 id 
等 于 12 的 记录 存储 在 排序 运行 批 次 2 中 。 换 句 话 说， 合并 利用 数据 在 溢出 到 临时 段 之 前 已 被 排序 的 事 
实 ， 以 便 顺 序 读 取 每 个 排序 运行 批 次 。 这 是 图 14-10 中 的 第 5 步 。 


14.3 合并 联接 493 


临时 表 空 间 网 


二 排序 运行 批 2 


排序 运行 批 次 1 1 
-5- 
于 必 区 
ID NPAD f 


11 11 n64C&KzymK9NhnLQOxVg \ .6- 


12 12 E(%1lqzO[iLmyowButwa/T 、 一 -一 一 一 一 
13 13 ‘n/I6t!HHAS9URrkMs'&No \ 

14 14 .r4?72prZ])%LGmsB/7ZQ' 1i5 

15 _ 15 VE&q) jm : J —5yOI8K%{<-~ 


图 14-10 磁盘 上 排序 ， 合并 阶段 


(0) 一 旦 以 正确 方式 排序 的 某 些 数据 可 以 访问 了 ， 就 能 将 它 返 回 给 父 操作 。 这 是 图 14-10 中 的 第 6 步 。 

在 刚刚 描述 的 例子 中 , 将 数据 写 入 到 临时 段 中 一 次 /从 临时 段 中 读 取 数 据 一 次 。 这 种 类 型 的 排序 被 
称 作 一 路 排序 (one-pass sort )。 当 工作 区 的 大 小 远 远 小 于 需要 排序 的 数据 总 量 时 ， 有 必要 经 历 多 次 合 
并 阶段 。 在 这 种 情况 下 , 会 多 次 将 数据 写 入 到 临时 段 中 /从 临时 段 中 多 次 读 取 数据 。 这 种 类 型 的 排序 称 
We ( multipass sort )。 显 然 ， 从 性 能 的 角度 看 ， 一 路 排序 应 该 比 多 路 排序 更 快 。 

识别 两 种 类 型 的 排序 ， 可 以 使 用 dbms _xplan 包 生成 的 输出 。 我 们 看 一 下 来 自己 经 在 上 一 小 节 中 

We 在 这 份 输出 中 ， 显 示 了 两 个 额外 的 列 : 1Mem 和 Used-Tmp。 前 者 估算 一 路 排序 
所 需 的 内 存 总 量 。 后 者 是 在 执行 期 间 由 操作 使 用 的 临时 段 的 实际 大 小 。 如 果 没 有 值 可 用 ， 4 味 着 
执行 的 是 内 存 中 排序 。 还 有 ， 注 意 对 于 使 用 临时 空间 的 操作 ， 括 号 之 间 的 值 不 再 是 0。 会 将 它们 的 值 
设置 为 执行 排序 的 次 数 。 换 名 话说， 操作 10 是 一 路 排序 ， 而 操作 12 是 多 路 (9 路 ) 排序 : 

SELECT 报 , 和 %, 科 . 半 生计 拒 外 ,类 

FROM: 4 七 2; 起 ; 直 

WHERE +t1.,id = t2.t1 id 

AND t2.id = t3.t2 id 


AND t3.id = t4.t3 id 
AND ti.n = 19 


0 | SELECT STATEMENT 
1 | MERGE JOIN | 
2 SORT JOIN | 34816 | 34816 |30720 (0) 1024 
3 MERGE JOIN 

4 SORT JOIN 5120 5120 | 4096 (0) 
5 MERGE JOIN 
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| 6| SORT JOIN | 3072 | 3072 | 2048 (0)| | 
陆 子 | TABLE ACCESS FULL| T1 | | | | | 
:| SORT JOIN | 9216 | 9216 |18432 (0)| 1024 | 
| 91 TABLE ACCESS FULL| T2 | | | | | 
|* 10 | SORT JOIN | 99K| 99K|32768 (1)| 1024 | 
| 她 | TABLE ACCESS FULL | T3 | | | | | 
|* 12 | SORT JOIN | 954Kk| 532K|41984 (9)| 2048 | 
| 13 | TABLE ACCESS FULL T4 | | | | | 


7 - filter("T1"."N"=19) 
8 = dccess( "Ti .10"="T2" .1 
filter("T1" "TD Ta. "Ty ITD" 
40 = access("T2"."ID"="T3"." 
filter("T2" "ID"="T3""12 ID’ 
12, - access("T3"."ID"="T4"."13 ID" 
filter("T3"."ID"="T4"."T3_ID" 


警告 ”通常 dbms_xplan 的 输出 以 字 节 为 单位 显示 关于 内 存 大 小 的 值 。 遗憾 的 是 ,就 像 在 第 10 章 中 指出 
的 那样 ， 位 于 Used-Tmp 列 中 的 值 必须 乘 以 1024 以 转换 为 字 节 。 举 例 来 说 ， 在 上 面 的 输出 中 ， 操 
作 10 和 操作 12 分 别 使 用 了 1 MB 和 2 MB 的 临时 空间 。 


14.4 ” 散 列 联接 


本 节 介 绍 散 列 联接 如 何 工作 。 首 先 会 描述 散 列 联接 的 常规 行为 并 提供 一 些 两 表 联 接 和 四 表 联 接 的 
例子 ， 接 下 来 会 对 处 理 期 间 使 用 的 工作 区 进行 描述 。 最 后 ， 会 介绍 一 种 特殊 的 优化 技术 ， 索 引 联接 
所 有 例子 都 基于 hash_join.sql 脚 本 。 


14.4.1 概念 


由 散 列 联接 处 理 的 两 组 数据 称 作 构建 输入 (build input ) 和 探测 输入 ( probe input )。 构建 输入 是 
左 输入 ,探测 输入 是 右 输入 - 如 图 14-11 所 示 , 使 用 构建 输入 的 每 一 行 , 在 内 存 中 ( 如 果 没 有 足够 的 内 
存 可 用 ， 也 会 使 用 临时 表 空 间 ) 构建 出 散 列 表 。 注 意 用 于 此 用 途 的 散 列 键 是 根据 用 作 联 接 条 件 的 列 计 
算得 来 。 一 旦 散 列表 包含 来 自 构 建 输 入 的 所 有 数据 ， 就 开始 探测 输入 的 处 理 过 程 。 每 一 行 都 会 针对 散 
列表 进行 探测 以 找 出 它 是 否 满足 联接 条 件 。 显 然 ， 只 有 匹配 的 记录 会 被 返回 。 

散 列 联接 拥有 的 具体 特征 如 下 所 示 。 

口 构建 输入 仅 执行 一 次 。 

口 探测 输入 至 多 执行 一 次 。 如 果 构 建 输入 不 返回 任何 数据 并 且 没 有 使 用 右 外 联接 或 全 外 联接 ， 

探测 输入 根本 不 会 执行 。 

口 散 列 表 仅 构建 于 构建 输入 之 上 。 所 以 ， 通 常 它 构建 于 最 小 的 输入 上 。 

口 在 返回 第 一 行 数据 之 前 ， 只 有 构建 输入 需要 被 完全 处 理 。 

口 不 文 持 交叉 联接 、 内 联接 以 及 已 分 区 外 联接 。 
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RS | 


读 取 探 索 输 入 


图 14-11 由 散 列 联接 执行 的 处 理 过 程 概览 


14.4.2 ”两 表 联 接 


下 面 是 一 个 处 理 两 表 之 间 散 列 联接 的 简单 执行 计划 。 该 例子 还 展示 了 如 何 依 靠 leading 和 use_hash 
hint 来 强制 执行 散 列 联接 : 
SELECT /*+ leading(t1 t2) use hash(t2) */ * 


FROM t1, t2 

WHERE t1.id = t2.t1 id 

AND ti.n = 19 

| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
|* 1 | HASH JOIN | | 
|* 2 | TABLE ACCESS FULL| T1 | 
| :| TABLE ACCESS FULL| T2 | 


1 - ‘access("T1"."ID"="T2"."T1 1D") 
2 - filter("T1"."N"=19) 
如 第 10 章 中 所 描述 的 ，HASH JOIN 是 无 关联 组 合 类 型 的 操作 。 这 意味 着 两 个 子 操作 至 多 被 处 理 一 次 
并 且 互 相 独立 。 在 这 种 情况 下 ， 执 行 计划 的 处 理 过 程 可 以 总 结 为 以 下 步 又 。 
口 表 t1 的 所 有 数据 通过 一 次 全 扫描 读 取 , 应 用 n=19 这 个 限制 条 件 , 然后 构建 出 一 个 使 用 该 结果 数 
据 的 散 列 表 。 为 构建 该 散 列表 ， 会 将 一 个 散 列 函数 应 用 到 用 作 联 接 条 件 的 列 ( id ) 上 。 
口 表 t2 的 所 有 数据 都 通过 一 次 全 扫描 读 取 ， 然 后 会 将 散 列 函数 应 用 到 用 作 联 接 条 件 的 列 上 
( t1_id )， 接 下 来 探测 该 散 列 表 。 如 果 找 到 匹配 ， 就 返回 结果 数据 。 
HASH JOIN 操作 最 重要 的 限制 是 其 没有 能 力 将 索引 应 用 于 联接 条 件 。 这 意味 着 索引 仅 能 在 指定 限 
制 条 件 的 情况 下 用 作 访 问 路 径 。 因 此 ， 为 了 选择 访问 路 径 ， 有 必要 为 两 张 表 都 应 用 第 10 章 中 讨论 的 方 
法 。 举 个 例子 ， 如 果 n=19 这 个 限制 条 件 提 供 强 选 择 性 ， 创 建 如 下 索引 并 应 用 可 能 会 很 有 帮助 ; 
CREATE INDEX tl n ON t1 (n) 


事实 上 , 有 了 这 个 索引 , 就 会 使 用 下 面 的 这 个 执行 计划 。 注意 , 表 t1 不 再 通过 全 表 扫 描 来 访问 了 : 
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| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
|* 1 | HASH JOIN | | 
| P| TABLE ACCESS BY INDEX ROWID| T1 | 
|* 3| INDEX RANGE SCAN | TiN | 
| 4 | TABLE ACCESS FULL IT | 


1 - access("T1"."ID"="T2","T1 ID") 
3 - access("T1"."N"=19) 


14.4.3 ”四 表 联 接 


下 面 的 执行 计划 是 一 个 典型 的 通过 散 列 联接 实现 左 深 树 ( 图 示 请 参见 图 14-2 ) 的 例子 。 该 例子 还 
展示 了 如 何 使 用 leading 和 use_hash 这 两 个 hint 来 强制 执行 散 列 联接 : 


SELECT /*+ leading(t1 t2 t3 t4) use hash(t2 t3 t4) */ t1.*, t2.*, t3.*, t4.* 
FROM t1i, t2, t3, t4 

WHERE t1.id = t2.t1 id 

AND t2.id = t3.t2 id 

AND t3.id = t4.t3 id 


AND t1i.n = 19 

| Id | 0peration | Name 

| 0 | SELECT STATEMENT | 

|* 1 | HASH JOIN | 

|* 2 | HASH JOIN | 

| 本 中 HASH JOIN | 

I 到 旧 | TABLE ACCESS FULL| T1 二 
|] 到 | TABLE ACCESS FULL| T2 

| 6| TABLE ACCESS FULL | T3 

| 7| TABLE ACCESS FULL | T4 


Ws access("T3"."ID"="T4"."T3_ID") 
2 - access("T2" "TD"="T3". "T2 TD) 
$§ - access( "TI. "TD"="T2". "TL ID) 
4 - filter("T1"."N"=19) 


这 种 类 型 的 执行 计划 的 处 理 过 程 如 下 所 示 。 

口 表 t1 通 过 全 扫描 读 取 ， 应 用 n=19 这 个 限制 条 件 ， 然 后 创建 包含 结果 数据 的 散 列 表 ， 

口 表 t2 通 过 全 扫描 读 取 ， 探 测 上 一 步 中 创建 的 散 列表 。 然 后 创建 包含 结果 数据 的 散 列 表 。 

口 表 t3 通 过 全 扫描 读 取 . 探测 上 一 步 中 创建 的 散 列表 。 然 后 创建 包含 结果 数据 的 散 列表 。 

口 表 t4 通 过 全 扫描 读 取 , 探测 上 一 步 中 创建 的 散 列表 , 然后 返回 结果 数据 。 仅 当 已 全 部 处 理 完 t1、 

t2 和 t3 表 时 才 可 以 返回 第 一 行 。 反 之 ,返回 第 一 行 数据 之 前 没有 必要 全 部 处 理 完 表 t4。 

散 列 联接 的 一 个 特别 的 属性 是 它 还 支持 右 深 树 和 曲折 树 。 下 面 的 这 个 执行 计划 是 前 者 的 一 个 例子 

( 图 示 请 参见 图 14-3 ), 对 比 上 一 个 例子 , 只 有 在 SQL 语句 中 指定 的 hint 有 所 不 同 。 注意, 在 这 种 情况 下 ， 
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leading 这 个 hint 并 不 直接 指定 访问 表 的 顺序 ( 也 就 是 tl > t2 > t3 > t4)。 反之， 它 指定 在 应 用 要 求 
交换 左右 输入 的 swap_join_inputs hint 之 前 的 顺序 : 


SELECT /*+ leading(t3 t4 t2 t1) use hash(t1 t2 t4) swap join inputs(t1) 
swap_join inputs(t2) */ t1.*, t2.*, t3.*, t4.* 

FROM ti, t2, t3, t4 

WHERE t1.id = t2.t1 id 

AND t2.id = t3.t2 id 

AND t3.id = t4.t3 id 


AND t1.n = 19 

| Id Operation Name | 
| 0 | SELECT STATEMENT 

|* 1 | HASH JOIN 

| 空 用 TABLE ACCESS FULL T1 

|* 3 | HASH JOIN 

| 4 TABLE ACCESS FULL | T2 

|* 5 HASH JOIN 

| 6 TABLE ACCESS FULL| T3 

| 7 TABLE ACCESS FULL| T4 


1 - access("T1"."ID"="T2","T1 ID") 
2 - filter("T1"."N"=19) 

3 - access("T2"."ID"="T3"."T2 ID") 
5 - access("T3"."ID"="T4"."T3 ID") 


列表 ) 的 数量 。 使 用 左 深 树 时 ， 在 同一 时 间 最 多 有 两 工作 区 可 使 用 。 此 外 ， 当 处 理 最 后 的 表 时 ， 只 需 
要 一 个 单独 工作 区 。 男 一 方面 ， 在 右 深 树 中 ， 在 几乎 整个 执行 时 间 中 都 会 分 配 和 探测 若干 工作 区 ( 其 
数量 等 于 联接 的 数量 )。 两 个 执行 计划 之 间 的 另 一 个 区 别 是 它们 的 工作 区 大 小 。 鉴 于 右 深 树 工 作 区 包 
含 来 自 单 张 表 的 数据 ， 而 左 深 树 工作 区 可 以 包含 来 自 多 张 表 联接 的 结果 数据 。 因 此 ， 左 深 树 工 作 区 的 
大 小 依赖 于 联接 是 否 限 制 返回 的 数据 总 量 。 

v$sql_workarea_active 动 态 性 能 视图 提供 关于 活动 工作 区 的 信息 。 下 面 的 查询 显示 正在 执行 上 面 
的 执行 计划 的 一 个 会 话 所 使 用 的 工作 区 。 虽 说 operation_id 列 用 于 关联 工作 区 和 执行 计划 中 的 操作 ， 
actual _mem_used 列 显示 其 大 小 ( 按 字 节 ), 而 tempseg_size 和 tablespace 列 则 给 出 关于 临时 表 空 间 使 用 

SQL> SELECT operation id, operation type, actual mem used, tempseg size, tablespace 

2 FROM v$session s, v$sql workarea active w 
WHERE s.sid = w.sid 


3 
4 AND s.sid = 24 
5 ORDER BY operation id; 


OPERATION ID OPERATION TYPE ACTUAL MEM USED TEMPSEG SIZE TABLESPACE 
1 HASH-JOIN 79872 
3 HASH-JOIN 161792 
5 HASH-JOIN 185344 1048576 TEMP 
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14.4.4 工作 区 


为 了 处 理 散 列 联接 ， 会 将 内 存 中 的 工作 区 用 于 存储 散 列 的 数据 。 如果 工作 区 足够 大 ， 能 够 存储 束 
个 散 列 表 ， 则 散 列 联接 会 完全 在 内 存 中 处 理 。 如 果 工 作 区 不 够 大 ， 则 会 将 数据 溢出 到 临时 段 中 。( 在 
本 章 前 面部 分 解释 过 如 何 分 辩 完 全 在 内 存 中 执行 的 联接 。 ) 

我 在 第 9 章 讨论 过 工作 区 配置 (设置 大 小 )。 就 像 你 可 能 回想 起 来 的 那样 ， 有 两 种 方法 可 用 来 执行 
设置 大 小 。 有 具体 使 用 哪 一 种 取决 于 workarea_size_policy 初 始 化 参数 的 值 。 

口 auto: 数据 库 引 擎 自动 设置 工作 区 的 大 小 。 一 个 实例 拥有 的 PGA 总 量 由 pga_aggregate target 

初始 化 参数 控制 ， 或 者 从 11.1 版 本 开始 ， 由 memory_target 初 始 化 参数 控制 。 
口 manual: hash_area_size 初 始 化 参数 限制 一 个 单独 的 工作 区 的 最 大 大 小 。 


14.4.5 索引 联接 


索引 联接 只 能 通过 散 列 联接 执行 。 因 为 这 一 点 ， 可 以 认为 它们 是 散 列 联接 的 特殊 案例 。 其 用 途 是 
通过 联接 属于 相同 表 的 两 个 或 更 多 的 索引 来 避免 昂贵 的 表 扫 描 。 当 一 张 表 拥 有 许多 被 索引 的 列 ， 并 是 
其 中 几 张 表 被 一 条 SQL 语句 引用 时 ， 这 个 特性 可 能 会 非常 有 用 。 下 面 的 查询 是 一 个 例子 。 注 意 这 个 查 
询 如 何 引 用 一 张 单独 的 表 ， 但 是 不 管 你 期 待 的 可 能 是 什么 ， 都 会 执行 一 个 联接 以 取代 单 表 访问 。 还 有 
很 重要 的 一 点 是 ， 两 个 数据 集 之 间 的 联接 条 件 是 基于 rowid 的 。 该 例子 还 展示 如 何 通 过 index join 这 个 
hint 强制 执行 索引 联接 : 


SELECT /*+ index join(t4 t4 n t4 pk) */ id, n 


FROM t4 

WHERE id BETWEEN 10 AND 20 

AND n «< 100 

| Id | Operation | Name 

| 0 | SELECT STATEMENT | | 
|* 1 | VIEW | index$ join$ 001 | 
|* 2 | HASH JOIN | | 
|* 3 | INDEX RANGE SCAN| T4N | 
| 二 4 | INDEX RANGE SCAN| T4_PK | 


1 - filter("ID"<=20 AND "N"<100 AND "ID">=10) 
2 - access(ROWID=ROWID) 
3 = access("N"<100) 
4 - access("ID">=10 AND "ID"<=20) 
索引 联接 的 一 个 有 趣 的 限制 条 件 是 , 如 果 在 SELECT 子 句 中 引用 了 表 的 rowid,， 则 查询 优化 器 不 会 选 
择 它们 。 因 为 rowid 始 终 是 索引 的 一 部 分 , 这 个 限制 条 件 的 起 源 是 当前 的 实现 ,而 不 是 因为 索引 本 身 缺 
乏 必 要 的 信息 。 
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14.5 ”外 联接 


前 面 章节 中 描述 的 三 种 基本 联接 方法 都 支持 外 联接 。 当 执行 外 联接 时 ， 在 执行 计划 中 唯一 可 见 的 
区 别 就 是 追加 到 联接 操作 后 面 的 OUTER 关 键 字 。 为 了 演示 ， 执 行 下 面 的 SQL 语句 ， 因 为 hint 的 原因 ， 执 
行 计划 使 用 了 散 列 外 联接 。 注意, 即使 SQL 语句 是 使 用 新 的 联接 语法 书写 的 ,谓词 还 是 使 用 了 基于 (+) 
运算 符 的 Oracle 专 有 语法 : 


SELECT /*+ leading(t1) use hash(t2) */ * 
FROM t1 LEFT JOIN t2 ON t1.id = t2.t1 id 


| Id | Operation | Name | 
| 0 | SELECT STATEMENT | | 
|* 1 | HASH JOIN OUTER | | 
| 2| TABLE ACCESS FULL| T1 | 
| 3| TABLE ACCESS FULL| T2 | 


1 - access("T1"."ID"="T2"."T1 ID"(+)) 
除了 是 右 外 联接 的 散 列 联接 ,保留 表 ( 例如 ,上 面 SQL 语句 中 的 t4 表 ) 必须 是 联接 操作 的 左 输入 。 
下 面 的 执行 计划 ， 基 于 与 上 面 例子 相同 的 SQL 语句 ， 证 实 了 这 一 点 。 在 实践 中 ,查询 优化 器 选择 在 最 
小 的 结果 集 上 构建 散 列 表 。 当 然 了 ， 这 对 于 限制 工作 区 的 大 小 会 有 帮助 。 在 本 例 中 ， 因 为 表 t4 要 小 于 
表 t2， 出 于 演示 的 目的 ， 有 必要 使 用 swap_ join _inputs hint 强 制 查询 优化 器 交换 两 个 联接 输入 : 
SELECT /*+ leading(t1) use hash(t2) swap_ join inputs(t2) */ * 
FROM t1 LEFT JOIN t2 ON t1.id = t2.t1 id 


0 | SELECT STATEMENT | | 
* 1 | HASH JOIN RIGHT OUTER| | 
2 | TABLE ACCESS FULL |T2 | 
3 | TABLE ACCESS FULL |T1 | 


1 - access("T1"."ID"="T2"."T1 ID"(+)) 
因此 , 无 论 何 时 查询 优化 器 必须 为 一 条 SQL 语句 生成 一 个 包含 外 联接 的 执行 计划 , 除了 散 列 联接 ， 
它 的 选择 是 非常 有 限 的 。 


14.6 ”选择 联接 方法 
要 选择 一 种 联接 方法 ， 必 须 考虑 以 下 三 个 问题 : 


口 优化 器 目标 ， 即 first-rows 优 化 和 all-rows 优 化 ; 
口 要 优化 的 联接 类 型 和 谓词 的 选择 率 ; 


500 第 14 章 ”优化 联接 


口 是 否 会 以 并 行 方式 执行 联接 。 
基于 这 三 个 准则 ， 接 下 来 的 小 节 讨 论 如 何 选 择 一 种 联接 方法 , 或 者 更 具体 点 说 ， 如 何在 授 套 循环 
联接 、 合 并 联接 以 及 散 列 联接 之 间 进 行 选择 。 


14.6.1 First-Rows 优化 


使 用 first-rows 优 化 时 ， 总 体 响 应 时 间 是 查询 优化 器 的 次 要 目标 。 返 回 开始 若 干 行 数据 的 响应 时 间 
显然 是 最 重要 的 目标 。 因 此 ， 对 于 成 功 的 first-rows 优 化 ， 联 接应 该 尽 可 能 快 地 返回 首先 发 现 的 匹配 数 
据 ， 而 不 是 等 待 所 有 数据 都 处 理 完 毕 。 出 于 这 个 目的 ， 骨 套 循环 联接 经 常 是 最 佳 选择 。 散 列 联接 ， 仅 
在 某 种 程度 上 支持 部 分 的 联接 ， 时 而 可 用 。 比 较 起 来 ， 合 并 联接 则 很 少 适 用 于 first-rows 优 化 。 


14.6.2 ”All-Rows 优化 


使 用 all-rows 优 化 ， 返 回 最 后 一 行 的 响应 时 间 是 查询 优化 器 最 重要 的 目标 。 因 此 ， 对 于 成 功 的 
all-rows 优 化 ， 联 接应 该 尽 可 能 迅速 地 完全 执行 。 为 选择 最 佳 的 联接 方法 ， 将 逻辑 读 的 数量 减 到 最 小 ， 
必须 考虑 是 否 有 必要 利用 索引 来 应 用 联接 条 件 。 如 果 有 必要 通过 一 个 索引 来 应 用 联接 条 件 ， 就 必须 使 
用 冉 套 循环 联接 。 和 否则 ， 散 列 联接 通常 是 最 好 的 选择 。 通 常 来 说 ， 仅 当 结 果 集 已 排 过 序 或 因为 技术 限 
制 ( 见 14.6.3 节 ) 无 法 使 用 散 列 联接 时 ， 才 会 考虑 合并 联接 。 另 一 个 可 能 比较 有 趣 的 合并 联接 的 案例 
出 现在 可 以 避免 排序 操作 的 时 候 。 当 合并 联接 返回 记录 是 按照 ORDER BY 子 句 指定 的 顺序 时 ， 就 会 发 生 
这 种 情况 。 


14.6.3 ”支持 的 联接 方法 


要 选择 一 种 联接 方法 ， 必 须要 知道 需要 执行 的 联接 的 类 型 。 事 实 上 ,， 并非 所 有 联接 方法 都 支持 所 
有 联接 类 型 。 表 14-1 总 结 了 在 不 同情 况 下 可 用 的 联接 方法 。 


表 14-1 各 联接 方法 支持 的 联接 类 型 


联 接 嵌 套 循环 联接 散 列 联接 合并 联接 
交叉 联接 y Y 
内 联接 y 对 
等 值 联 接 Y y 
半 / 反 联接 y y y 
外 联接 Y y y 
已 分 区 外 联接 y y 


14.6.4 ”并行 联接 


所 有 联接 方法 都 能 以 并 行 方式 执行 。 不 过 , 如 图 14-12 所 示 , 它们 依 不 同比 例 决定 。 取 决 于 并 行 度 ， 
一 种 方法 可 能 会 比 另 一 种 更 快 。 所 以 ， 为 选择 出 最 佳 的 联接 方法 ,一定 要 了 解 是 否 使 用 了 并 行 处 理 以 
及 并 行 度 是 多 少 。( 第 15 章 介绍 并 行 处 理 。) 
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2 做 套 循环 
捍 一 合并 连接 
一 一 散 列 连接 


响应 时 间 ( 秒 ) 


图 14-12 不 同 并 行 度 下 的 性 能 对 比 。 此 图 展示 的 是 在 一 个 拥有 8 个 内 核 的 系统 上 执行 的 
两 表 联接 


14.7 分 区 智能 联接 


分 区 智能 联接 ( partition-wise join， 不 要 与 已 分 区 外 联接 混淆 ) 是 一 项 查询 优化 器 仅 会 将 其 应 用 
于 合并 和 散 列 联接 的 优化 技术 。 分 区 智能 联接 用 于 减少 CPU 、 内 存 使 用 总 量 ， 以 及 ,在 RAC 环 境 中 ， 
减少 用 于 处 理 联接 的 网 络 资源 。 其 基本 思路 是 将 一 个 大 的 联接 拆 分 成 多 个 较 小 的 联接 。 分 区 智能 联 
接 可 以 是 完全 的 或 部 分 的 。 接 下 来 的 小 节 描述 这 两 种 选择 .所 有 作为 例子 使 用 的 查询 都 在 脚本 pwj .sql 
中 提供 ， 


注意 ”分 区 智能 联接 需要 已 分 区 表 。 因 此 ， 仅 在 使 用 了 企业 版 中 的 分 区 选项 时 ， 这 些 技术 才 可 用 。 


14.7.1 完全 智能 化 分 区 联接 


为 了 演示 完全 智能 化 分 区 联接 的 操作 , 我 们 首先 来 描述 一 下 不 使 用 这 项 优化 技术 的 联接 是 怎么 执 
行 的 。 图 14-13 展 示 两 张 已 分 区 表 之 间 的 一 个 联接 。 两 张 表 所 有 数据 行 的 一 个 单独 的 联接 由 一 个 单独 的 
服务 进程 来 执行 。 

当 两 张 表 在 它们 的 联接 键 上 是 对 等 分 区 ( equi-partitioned ) 时 ( 例如， 一 张 基 于 指向 它 的 父 表 的 
外 键 参照 分 区 的 子 表 )， 数 据 库 引擎 能 够 利用 完全 智能 化 分 区 联接 。 取 代 执 行 一 个 单独 的 大 联接 ， 如 
图 14-14 所 示 ， 它 执行 多 个 较 小 的 联接 ( 在 本 例 中 ， 四 个 )。 注 意 这 样 做 可 行 是 因为 这 两 张 表 是 以 相同 
的 方式 分 区 的 。 因 此 ， 表 1 的 分 区 1 中 存储 的 每 一 行 仅 在 表 2 的 分 区 1 中 有 匹配 的 行 。 

在 将 一 个 大 的 联接 分 解 为 多 个 较 小 联接 的 过 程 中 , 其 中 一 件 最 有 用 的 事情 就 是 提高 执行 过 程 并 行 
化 的 可 能 性 。 事 实 上 ， 数据库 引擎 能 够 为 每 个 联接 启动 一 个 独立 的 从 属 进程 。 举 例 来 说 ， 在 图 14-14 
中 服务 进程 协调 四 个 从 属 进程 来 执行 完全 智能 化 分 区 联接 。( 第 15 章 提供 关于 并 行 处 理 的 详细 信息 。) 
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图 14-14 ”使 用 智能 化 分 区 联接 来 联接 两 种 已 分 区 表 


图 14-15 展 示 的 是 基于 pwj_performance.sql 脚 本 的 一 个 性 能 测试 的 结果 。 这 个 测试 的 目的 是 重 现 类 
似 图 14-14 中 演示 的 那样 的 执行 , 或 者 , 具体 点 说 , 重 现 拥 有 四 个 分 区 的 两 张 表 的 一 个 联接 。 在 这 个 特 
别 的 例子 中 ， 表 中 分 别 包 含有 10 000 000 和 100 000 000 行 数据 。 注 意 ， 并 行 执行 的 并 行 度 等 于 分 区 的 
数量 ， 即 四 个 。 


Serial without PWJ 
图 14-15 两 表 联 接 在 使 用 和 不 使 用 完全 智能 化 分 区 联接 的 情况 下 分 别 的 啊 应 时 间 


为 了 识别 是 否 使 用 了 完全 智能 化 分 区 联接 ， 有 必要 查看 一 下 执行 计划 。 如 果 分 区 操作 在 联接 操作 
之 前 出 现 ， 则 意味 着 使 用 了 完全 智能 化 分 区 联接 。 在 下 面 的 执行 计划 中 ，PARTITION HASH ALL 操 作 就 
是 在 HASH JOIN 操 作 之 前 出 现 的 : 

SELEEF 二 


FROM t1ip, t2p 
WHERE t1p.id = t2p.id 


| Id | Operation | Name | 


0 | SELECT STATEMENT | | 
1 | PARTITION HASH ALL | | 
|* 2 | HASH JOIN | | 
3 | TABLE ACCESS FULL| Tip | 
4 | TABLE ACCESS FULL| Tz2p | 


2 - access("T1iP"."ID"="T2P"."ID") 

上 面 的 执行 计划 显示 的 是 一 个 串 行 的 完全 智能 化 分 区 联接 。 接 下 来 展示 对 于 完全 相同 的 SQL 语 句 
使 用 并 行 处 理 的 执行 计划 。 还 有 在 这 个 案例 中 ，PX PARTITION HASH ALL 操 作 的 出 现 要 早 于 HASH JOIN 
操作 。 注意 是 如 何 使 用 pq_distribute hint 来 通知 查询 优化 器 使 用 完全 智能 化 分 区 联接 的 ( 第 15 章 提供 
关于 用 于 并 行 处 理 的 操作 的 详细 信息 ): 

SELECT /*+ ordered use hash(t2p) pq distribute(t2p none none) */ * 


WHERE t1p.id = t2p.id 


| Id | Operation | Name | 
0 | SELECT STATEMENT | | 
| 1 | PX COORDINATOR | | 

2 | PX SEND QC (RANDOM) | :TQ10000 | 
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| PX PARTITION HASH ALL| | 
| HASH JOIN | | 
| TABLE ACCESS FULL | TiP | 
| TABLE ACCESS FULL | T2P | 


4 - access("T1P"."ID"="T2P"."ID") 
因为 完全 智能 化 分 区 联接 需要 两 张 对 等 分 区 的 表 , 特别 注意 的 是 有 必要 在 物理 数据 库 设计 期 间 就 
使 用 这 项 优化 技术 。 换 名 话说 ， 通 常 预期 对 等 分 区 的 表 会 遭遇 大 量 的 联接 。 如 果 不 将 它们 对 等 分 区 ， 
则 无 法 从 完全 智能 化 分 区 联接 中 获 益 。 


警告 ” 当 两 张 表 在 相同 的 值 列表 上 定义 了 相同 数量 的 分 区 时 ， 且 当 分 区 按照 相同 的 顺序 进行 定义 时 ， 
会 将 两 张 列 表 已 分 区 的 表 视 为 对 等 分 区 的 。pwj_list.sql 脚 本 演示 了 这 个 限制 。 


还 有 一 件 事情 需要 注意 ,所 有 的 分 区 方法 都 是 受 支 持 的 , 并且 完 全 智能 化 分 区 联接 能 够 联接 分 区 
和 子 分 区 。 举 例 而 言 ， 假 如 说 你 有 两 张 表 : sales 和 customers。 联 接 键 是 customer id。 如 果 两 张 表 都 
是 散 列 分 区 的 ， 拥 有 相同 数量 的 分 区 ， 而 且 两 张 表 都 使 用 联接 键 作 为 分 区 键 ， 则 可 以 利用 完全 智能 化 
分 区 联接 。 一 定 要 记 住 ， 通常 对 一 张 类 似 sales 这 样 的 表 ( 换 句 话说， 一 张 包含 历史 数据 的 表 ) 分 区 
时 需要 的 是 范围 分 区 。 在 这 种 情况 下 ， 可 以 为 sales 表 使 用 组 合 分 区 。 组 合 分 区 是 通过 在 分 区 级 别 实 
施 范围 分 区 , 在 子 分 区 级 别 使 用 散 列 分 区 来 实现 的 ,以 满足 两 种 需求 。 因 此 ,就 可 以 在 customers 表 的 
散 列 分 区 和 sales 表 的 子 分 区 之 间 执 行 完 全 智能 化 分 区 联接 。 
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与 完全 智能 化 分 区 联接 相 比 ， 部 分 智能 化 分 区 联接 并 不 要 求 两 张 对 等 分 区 的 表 。 此 外 ， 只 有 一 张 
表 必 须 是 根据 联接 键 进行 分 区 的 ; 另外 一 张 表 ( 可 以 分 区 也 可 以 不 分 区 ) 是 根据 联接 键 动态 分 区 的 。 
部 分 智能 化 分 区 联接 的 另外 一 个 特性 是 它们 只 能 够 以 并 行 方 式 执行 .图 14-16 演 示 了 一 个 部 分 智能 化 分 
区 联接 。 在 这 个 案例 中 ， 其 中 的 一 张 表 根本 没有 进行 分 区 。 在 执行 期 间 ， 数 据 库 引 擎 启动 两 组 并 行 从 
属 进程 。 第 一 组 读 取 非 分 区 的 表 ( 表 2 ) 并 根据 分 区 键 对 数据 进行 分 区 。 第 二 组 接收 来 自 第 一 组 的 数 
据 ， 并 且 每 一 个 从 属 进程 读 取 已 分 区 表 的 一 个 分 区 ， 然 后 执行 它 自己 那 部 分 联接 。 

要 识别 是 否 使 用 了 部 分 智能 化 分 区 联接 ， 有 必要 查看 其 执行 计划 。 如 果 PX SEND 操 作 是 PARTITION 
(KEY) 类 型 的 ， 则 意味 着 使 用 了 部 分 智能 化 分 区 联接 。 在 下 面 的 例子 中 ， 操 作 7 提 供 了 这 个 信息 : 


SELECT /*+ ordered use hash(t2p) pq_distribute(t2p none partition) */ * 
FROM tip, t2p 
WHERE tlp.id = t2p.id 


0 | SELECT STATEMENT | | 
1 | PX COORDINATOR | | 
2 | PX SEND QC (RANDOM) | :TQ10001 | 
3 | HASH JOIN BUFFERED | | 
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| 4| PX PARTITION HASH ALL | | 
| 5| TABLE ACCESS FULL | Tip | 
| 6 | PX RECEIVE | | 
| PX SEND PARTITION (KEY)| :TQ10000 | 
| ,| PX BLOCK ITERATOR | | 
| 9| TABLE ACCESS FULL | T2P | 


3 = access("T1iP"."ID"="T2P"."ID") 


C2) 
中 进程 ey 
= 从 


[二 Pe OOO | 7 \ 
| 
I J Nd I 
I a zz | | 
| 
> | 
二 一 LA | 基于 分 区 键 
一 | 的 动态 分 区 | 
=|1 


图 14-16 使 用 部 分 智能 化 分 区 联接 来 联接 两 张 表 
在 实践 中 ， 部 分 智能 化 分 区 联接 并 不 一 定 会 引起 性 能 的 提升 。 事 实 上 ， 正常 的 联接 可 能 会 比 部 分 
智能 化 分 区 联接 更 快 。 因 为 使 用 部 分 智能 化 分 区 联接 可 能 会 对 性 能 不 利 ， 一般 很 少 会 看 见 查 询 优化 器 
使 用 这 种 优化 技术 。 


14.8” 星 型 转换 


星 型 转换 ( star transformation ) 是 一 项 用 于 星 型 模式 ( star schema, 也 称 作 维度 模型 ) 的 优化 技术 。 
这 种 类 型 的 模式 是 由 一 个 大 的 中 央 表 ( 事实 表 ) 以 及 几 个 其 他 的 表 ( 维度 表 ) 组 成 的 。 它 的 主要 特点 
是 事实 表 依赖 维度 表 。 图 14-17 是 一 个 基于 样 例 模 式 SH ( Sample Schemas 手 册 对 此 有 完整 描述 ) 的 例子 。 


注意 星 型 转换 仅 在 企业 版 中 可 用 。 要 想 在 标准 版 中 利用 一 种 类 似 的 优化 技术 ， 必 须 自 己 手动 重 写 
查询 。 在 本 节 的 结尾 会 提供 这 样 的 一 个 重 写 的 例子 。 


下 面 是 一 个 典型 的 针对 星 型 模式 执行 的 查询 ( 注意 ， 没 有 将 限制 条 件 应 用 于 事实 表 上 ， 而 只 是 应 
用 于 维度 表 上 ): 
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SELECT Cc.cust state province, t.fiscal month name, sum(s.amount sold) AS amount sold 
FROM sales s, customers c¢, times t, products p 

WHERE s.cust id = c.cust id 

AND s.time id = t.time id 

AND s.prod id = p.prod id 

AND c.cust year of birth BETWEEN 1970 AND 1979 

AND p.prod subcategory = 'Cameras' 

GROUP BY c.cust state province, t.fiscal month_ name 

ORDER BY c.cust state province, sum(s.amount sold) DESC 


图 14-17 一 个 典型 的 星 型 模式 


为 优化 这 个 针对 星 型 模式 的 查询 ， 查 询 优化 器 应 该 完成 以 下 几 件 事 。 

(1) 开始 评估 在 其 上 面 含有 限制 条 件 的 每 张 维 度 表 。 

(2) 使 用 产生 的 维度 键 装 配 一 个 列表 。 

(3) 使 用 该 列表 从 事实 表 中 提取 匹配 的 记录 。 

遗憾 的 是 ， 这 种 方法 无 法 使 用 正常 的 联接 实现 。 一 方面 ,查询 优化 器 在 同一 时 间 只 能 联接 两 组 数 
据 。 另 一 方面 ， 联 接 两 张 维 度 表 会 导致 第 卡 儿 积 的 出 现 。 为 了 解决 这 个 问题 ，Oracle 数 据 库 实现 了 星 
型 转换 。 


警告 尽管 星 型 转换 是 在 1997 年 的 8.0 版 本 中 首 度 引 入 的 ， 并 且 在 两 年 后 的 8.1 版 本 中 得 到 极 大 的 增 
强 ， 但 是 ， 在 之 前 的 很 长 一 段 时 间 ， 它 的 稳定 性 一 直 是 一 个 问题 。 可 能 自从 其 引入 之 后 发 布 
的 每 个 补丁 集 都 会 修复 一 些 与 其 相关 的 bug。 一 旦 有 什么 不 对 的 地 方 ， 就 会 生成 类 似 
ORA-07445、ORA-00600、ORA-00942 的 错误 ， 或 出 现 不 正确 的 结果 。 尽 管 如 此 ， 自 从 8.1.6 
版 本 开始 就 可 以 顺利 地 使 用 这 个 特性 了 -Oracle 的 查询 优化 器 开发 组 很 清楚 这 个 问题 ,并 为 11.2 
版 本 完全 重 写 了 这 部 分 代码 。 因 此 ， 在 最 近 的 版 本 中 它 的 稳定 性 得 到 了 改善 。 我 的 建议 很 简 
单 ， 就 是 仔细 对 其 进行 测试 。 如 果 它 运行 没 问 题 ， 可 以 考虑 其 在 性 能 方面 带 来 的 提高 。 如 果 
有 问题 ,至 少 你 在 将 其 用 于 生产 环境 之 前 就 会 知道 。 我 还 建议 你 查看 Oracle Support 文 档 47358.1 
( Init.ora Parameter ST4R_TRANSFORMATION_ENABLED Reference Note )。 此 文档 给 出 影响 每 
个 具体 版 本 的 一 个 bug 列 表 
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你 需要 满足 两 个 基本 的 要 求 才能 从 星 型 转换 中 获 益 。 首 先 , 必须 启用 该 特性 。 可 以 使 用 
star_transformation_enabled 初 始 化 参数 来 控制 它 , 注 意 , 因为 默认 情况 下 会 将 这 个 参数 设置 为 FALSE， 
所 以 默认 会 禁用 该 特性 。 要 启用 它 ， 应 该 将 它 设置 为 temp_disable 或 TRUE。 其 次 ， 在 事实 表 上 ， 引 用 
维度 表 的 每 个 联接 条 件 上 必须 都 建 一 个 索引 。 联 接 条 件 不 必 基 于 外 键 ， 但 是 如 果 外 键 确实 存在 ， 它 们 
有 助 于 查询 优化 器 找到 一 个 最 优 的 执行 计划 。 尽 管 查询 优化 器 可 以 在 运行 时 将 B 树 索引 转化 成 位 图 索 
引 ， 执 行 计划 使 用 位 图 索引 会 更 加 高 效 。 总 之 ,我 建议 出 于 最 佳 性 能 的 考虑 ， 在 每 一 个 联接 条 件 上 创 
建 外 键 和 位 图 索引 。 


提示 当 一 张 事实 表 和 一 张 维 度 表 之 间 的 联接 条 件 是 基于 多 个 列 时 ， 星 型 转换 有 时 是 不 受 支持 的 
因此 ,我 强烈 推荐 你 在 一 个 单独 的 列 上 使 用 联接 条 件 ， 并 进而 也 基于 单独 的 列 创建 外 键 和 位 
图 索引 


将 star_transformation_enabled 初 始 化 参数 设置 为 temp_disable 时 ,就 会 为 之 前 展示 的 SQL 语 句 使 
用 以 下 执行 计划 。 这 个 例子 ,与 接 下 来 的 例子 一 样 ， 都 来 自 star_transformation.sql 脚 本 : 


Id | Operation | Name 
0 | SELECT STATEMENT | 
1 SORT ORDER BY | 
2 HASH GROUP BY | 
村 HASH JOIN | 
4 | TABLE ACCESS FULL | TIMES 
区 有 HASH JOIN | 
类 | TABLE ACCESS FULL | CUSTOMERS 
7 | VIEW | WW_ST_FE4FBDB9 
8 | NESTED LOOPS 
9 BITMAP CONVERSION TO ROWIDS 
10 BITMAP AND | | 
11 BITMAP MERGE | | 
| 2 BITMAP KEY ITERATION | | 
| 33 | TABLE ACCESS BY INDEX ROWID| PRODUCTS 
|* 14 INDEX RANGE SCAN | PRODUCTS PROD SUBCAT IX | 
|* 15 BITMAP INDEX RANGE SCAN | SALES PROD BIX 
| 16 BITMAP MERGE | | 
和 BITMAP KEY ITERATION | | 
[le TABLE ACCESS FULL | CUSTOMERS 
|* 19 BITMAP INDEX RANGE SCAN | SALES CUST BIX 
| 20; | TABLE ACCESS BY USER ROWID | SALES 


3 - access("ITEM 1"="T"."TIME ID") 

5 - access("ITEM 2"="C"."CUST_ID") 

6 - filter("C"."CUST YEAR OF BIRTH">=1970 AND "C"."CUST YEAR OF _ BIRTH"<=1979) 
14 - access("P"."PROD SUBCATEGORY"="'Cameras') 

15 = access("S"."PROD TID"="P"."PROD ID") 

18 - filter("C"."CUST YEAR OF BIRTH">=1970 AND "C"."CUST YEAR OF BIRTH"<=1979) 
19 - access("S"."CUST ID"="C"."CUST ID") 
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因为 这 个 执行 计划 包含 一 些 特别 的 操作 ， 我 们 来 仔细 看 一 下 它 的 操作 。 

(1) 执行 始 于 操作 4， 对 times 维 度 表 的 全 表 扫 描 。 通 过 由 它 返 回 的 数据 ， 一 个 散 列表 被 操作 3 执行 
的 散 列 联接 建立 起 来 。 

(2) 操作 6 对 customers 维 度 表 做 了 一 次 全 表 扫 描 并 应 用 c.cust_year of _birth BETWEEN 1970 AND 
1979 这 个 限制 条 件 。 通 过 由 它 返 回 的 数据 ， 一 个 散 列 表 被 操作 5 执行 的 散 列 联接 建立 起 来 

(3) 操作 13 和 14 访 问 products 维 度 表 并 应 用 p.prod_subcategory='Cameras' 这 个 限制 条 件 

(4) 操作 12 BITMAP KEY ITERATION 是 一 个 关联 组 合 操 作 。 对 于 由 其 第 一 个 子 操作 ( 操作 13 ) 返回 的 
数据 ， 第 二 个 子 操作 ( 操作 15 ) 就 被 执行 一 次 。 在 此 情况 下 ， 就 对 基于 在 事实 表 上 定义 的 位 图 索引 执 
行 了 一 次 检索 。 

(5) 操作 11 BITMAP MERGE 合 并 由 它 的 子 操作 传递 过 来 的 位 图 。 这 个 操作 是 必要 的 ， 因 为 来 自 于 一 个 
位 图 索引 的 索引 键 可 能 只 会 覆盖 被 索引 表 的 一 部 分 。 

(6) 操作 16 到 19 按 照 与 操作 11 到 15 处 理 products 维 度 表 相同 的 方式 处 理 customers 维 度 表 ,事实 上 ， 
每 个 应 用 了 限制 条 件 的 维度 都 是 按照 相同 的 方式 处 理 的 。 

(7) 操作 10 BITMAP AND 组 合 从 它 的 两 个 子 操作 (11 和 16 ) 传递 过 来 的 位 图 并 且 仅 保留 匹配 的 条 目 

(8) 操作 9 BITMAP CONVERSION TO RONIDS 将 从 它 的 子 操作 ( 10 ) 传递 过 来 的 位 图 转换 为 sales 事 实 表 
的 rowid。 

(9) 操作 20 因 概 套 循环 联接 ( 操作 8 ) 而 访问 包含 由 操作 9 生成 的 rowid 的 事实 表 . 

(10) 操作 7 仅 是 提供 信息 的 ， 告 诉 你 查询 块 包含 一 个 来 自 星 型 转换 的 不 可 合并 的 结果 视图 ( 注意 
视图 名 称 的 VW_sT 前 级 )。 这 个 操作 仅 从 11.2.0.2 版 本 开始 才 可 用 。 

(11) 通过 由 操作 8 返回 的 记录 ， 对 两 个 散 列 联接 ( 操作 3 和 操作 5 ) 的 散 列表 进行 探测 。 如 果 找 到 
匹配 的 记录 ， 会 将 它们 传递 给 操作 2。 本 

(12) 操作 2 HASH GROUP BY 处 理 GROUP BY 子 句 并 将 结果 数据 发 送 给 操作 1。 

(13) 最 后 ， 操 作 1 SORT ORDER BY 处 理 ORDER BY 子 句 。 

概括 起 来 ， 完 成 一 次 星 型 转换 会 执行 以 下 步骤 。 

(1) 会 将 维度 表 与 事实 表 对 应 的 位 图 索引 相 “ 联 接 "”。 这 个 操作 仅 当 维度 表 拥 有 应 用 于 它们 的 限制 
条 件 时 才 是 必要 的 ， 在 本 例 中 ,是 products 和 customers 表 。 

(2) 会 将 结果 位 图 合并 转化 为 rowid。 然 后 通过 这 些 rowid 访 问 事实 表 。 

(3) 会 将 维度 表 与 从 事实 表 中 提取 出 来 的 数据 进行 联接 。 这 个 操作 仅 当 维度 表 在 WHERE 子 句 之 外 拥 
有 被 引用 的 列 时 才 是 必要 的 ， 在 本 例 中 ， 是 times 和 customers 表 。 这 就 是 customers 表 会 在 执行 计划 中 
出 现 两 次 的 原因 。 

你 可 以 为 这 个 基本 的 行为 应 用 另外 两 种 额外 的 优化 技术 : 临时 表 和 位 图 联接 索引 。 

临时 表 的 目的 是 避免 对 维度 表 的 双重 处 理 。 例 如 , 在 上 面 的 执行 计划 中 , 不 仅 customers 维 度 表 被 
通过 全 表 扫 描 访 问 了 两 次 ( 操作 6 和 操作 18 )， 而 且 应 用 于 它 的 谓词 也 被 执行 了 两 次 。 思 路 是 只 访问 每 个 
维度 一 次 ， 应 用 谓词 ， 并 将 结果 数据 存储 在 一 张 临时 表 中 。 这 项 优化 技术 会 在 star trans 
formation_enabled 初 始 化 参数 设置 为 TRUE 时 启用 。 下 面 的 执行 计划 是 一 个 例子 ， 也 是 基于 与 之 前 相同 
的 SQL 语 句 。 注 意 sys_temp_0fd9d6647_1cb85c 临 时 表 的 创建 ( 操作 1 到 操作 3 ) 和 它 的 使 用 ( 操作 7 和 操 
作 21 ): 
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Id Operation Name 
0 | SELECT STATEMENT 
上 TEMP TABLE TRANSFORMATION 
2 LOAD AS SELECT SYS_TEMP_0OFD9D6647_1CB85C 
-村 TABLE ACCESS FULL CUSTOMERS 
4 | SORT ORDER BY 
5 HASH GROUP BY 
” HASH JOIN | 
7 TABLE ACCESS FULL SYS_TEMP_ OFD9D6647_1CB85C 
* HASH JOIN 
9 TABLE ACCESS FULL TIMES 
10 VIEW VW_ST_16AF99B7 
她 NESTED LOOPS 
| 12 BITMAP CONVERSION TO ROWIDS 
13 BITMAP AND 
14 BITMAP MERGE 
15 


| 
| 
| 
| 
| 
| 
| 
BITMAP KEY ITERATION | 
| 
| 
| 
| 
| 
| 
| 
| 


| 
| | 
| | 
| | 
| | 
| | 
| | 

16 | TABLE ACCESS BY INDEX ROWID| PRODUCTS 

| | 
| | 
| | 
| | 
| | 
| | 
| | 


| 

| 

|+ 17 INDEX RANGE SCAN PRODUCTS_PROD_SUBCAT_IX 
|* 18 BITMAP INDEX RANGE SCAN SALES_PROD_BIX 

| 19 BITMAP MERGE 2 

| 20 BITMAP KEY ITERATION 

| 21 TABLE ACCESS FULL SYS_TEMP_0FD9D6647_1CB85C 
|* 22 BITMAP INDEX RANGE SCAN SALES CUST_BIX 

| 23 TABLE ACCESS BY USER ROWID SALES 


3 - filter("C"."CUST YEAR_OF_BIRTH">=1970 AND "C"."CUST YEAR_OF_BIRTH"<=1979) 
6 - access("ITEM 2"="CO") 

8 - access("ITEM 1"="T"."TIME ID") 

17 - access("P"."PROD SUBCATEGORY"="'Cameras') 

18 - access("S"."PROD ID"="P"."PROD ID") 

22 - access("S"."CUST ID"="C0") 

这 第 二 项 优化 技术 基于 位 图 联接 索引 。 思 路 是 避免 维度 表 与 对 应 的 事实 表 上 的 位 图 索引 之 间 的 
“联接 ”"。 出 于 这 个 目的 ,位 图 联接 索引 必须 在 事实 表 上 进行 创建 ， 并 对 维度 表 的 一 个 或 多 个 列 进行 索 
引 , 例 如 ,下 面 的 索引 分 别 对 于 应 用 c.cust year of birth BETWEEN 1970 AND 1979 和 p.prod_subcategory 
= 'Cameras' 限 制 条 件 是 有 必要 的 : 

CREATE BITMAP INDEX sales cust year of birth bix ON sales (c.cust year of birth) 


FROM sales s, customers c 
WHERE s.cust id = c.cust id 


CREATE BITMAP INDEX sales prod subcategory bix ON sales (p.prod subcategory) 
FROM sales s, products p 
WHERE s.prod id = p.prod id 


创建 了 这 两 个 索引 之 后 ， 就 产生 了 以 下 执行 计划 。 注 意 ， 用 于 产生 rowid 的 方法 (第 8~12 行 ) 要 
比 在 上 一 个 例子 中 使 用 的 那个 直截了当 得 多 。 实 际 上 ， 取 代 访 问 维 度 表 ,并 将 它们 与 事实 表 上 的 位 图 
索引 进行 联接 ， 仅 访问 位 图 联接 索引 就 足够 了 。 这 样 做 可 行 的 原因 是 与 维度 数据 有 关 的 值 已 经 呈现 在 
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事实 表 的 位 图 联接 索引 中 了 : 


| Id | Operation Name | 
| 0 | SELECT STATEMENT | 
| 1| SORT ORDER BY | | 
| 2| HASH GROUP BY | 
|* 3 | HASH JOIN | | 
| 4| TABLE ACCESS FULL | TIMES | 
|l* 51 HASH JOIN | 
|* 6 | TABLE ACCESS FULL CUSTOMERS 

j) 之 中 TABLE ACCESS BY INDEX ROWID | SALES | 
| 次] BITMAP CONVERSION TO ROWIDS | 
| 9| BITMAP AND | 
|» 36 | BITMAP INDEX SINGLE VALUE| SALES PROD SUBCATEGORY BIX 

| 4 | BITMAP MERGE | | 
|* 12 | BITMAP INDEX RANGE SCAN | SALES CUST YEAR OF BIRTH BIX | 


3 = atcess("S"."TIME ID"="T". TIME :ID") 

§ = aCesS( "S$"., "CUST ID"="C",. "CUST TD",) 

6 - filter("C"."CUST YEAR OF BIRTH">=1970 AND "C"."CUST YEAR OF BIRTH"<=1979) 
10 - access("S"."SYS NCO0009$"='Cameras') 

12 - access("S"."SYS NCO0008$">=1970 AND "S"."SYS NCOo0008$"<=1979) 


星 型 转换 是 一 种 基于 成 本 的 查询 转换 。 因 此 ， 当 启用 时 ,查询 优 化 器 不 仅 决定 使 用 星 型 转换 是 否 
合理 , 而且 决定 临时 表 和 /或 位 图 联接 索引 是 否 有 助 于 SQL 语句 的 高 效 执行 。 这 个 特性 的 使 用 也 可 以 通 
过 hint star_transformation 和 no_star_transformation 控 制 |。 

如 果 正 在 使 用 标准 版 ,那么 星 型 转换 和 位 图 索引 都 是 不 可 用 的 。 在 这 种 情况 下 ， 想 要 获得 较 好 的 
性 能 ， 可 能 需要 自己 手动 改写 查询 。 如 下 面 的 例子 所 示 ， 尽 管 重 写 的 查询 可 读 性 较 差 ， 执 行 计划 却 十 
分 相似 : 


SELECT c.cust state province, t.fiscal month name, sum(s.amount sold) AS amount sold 
FROM (SELECT * 
FROM sales 
WHERE rowid IN (SELECT c.rid 
FROM (SELECT s.rowid AS rid 
FROM customers c, sales 5 
WHERE c.cust id = s.cust id 
AND c.cust year of birth BETWEEN 1970 AND 1979) c， 
(SELECT s.rowid AS rid 
FROM products p, sales s 
WHERE p.prod id = s.prod id 
AND p.prod subcategory = 'Cameras') p 
WHERE c.rid = p.rid)) s, 
customers c, times t 


WHERE s.cust id = c.cust id 

AND s.time id = t.time id 

GROUP BY c.cust state province, t.fiscal month_ name 
ORDER BY c.cust state province, sum(s.amount sold) DESC 


14.9 ”小 结 人 


Id | 0peration Name 
0 | SELECT STATEMENT 
1 | SORT ORDER BY . | 
2 HASH GROUP BY 
此 村 HASH JOIN | 
| 4 TABLE ACCESS FULL TIMES | 
| 世上 | HASH JOIN | 
6 TABLE ACCESS FULL CUSTOMERS 
7 VIEW 
8 NESTED LOOPS 
| 9 | VIEW | VW_NSO 1 
10 HASH UNIQUE | 
FE : 测 HASH JOIN 
12 | VIEW 
We NESTED LOOPS | 
本 TABLE ACCESS BY INDEX ROWID| PRODUCTS 
| INDEX RANGE SCAN | PRODUCTS PROD SUBCAT IX | 
Ea INDEX RANGE SCAN | SALES PROD BIX 
| 17 | VIEW mn | 
| 18 | NESTED LOOPS -| | 
|* 19 | TABLE ACCESS FULL | CUSTOMERS 
|#* 20 | INDEX RANGE SCAN | SALES CUST_ BIX 
| 21 | TABLE ACCESS BY USER ROWID | SALES 


3 = access("S"."TIME ID"="T","TIME ID") 

5 ~ access("s"."CUST ID"s"C" "CST LID") 

11 = Heess("C". RID"="Pp", "RID") 

15 - access("P"."PROD SUBCATEGORY"="'Cameras') 
16 - access("P"."PROD ID"="S"."PROD ID") 

19 - filter("C",."CUST YEAR OF_ BIRTH">=1970 AND 

"C"."CUST_YEAR_OF BIRTH"<=1979) 

20 - access("C"."CUST ID"="S"."CUST ID") 


14.9 小结 


本 章 描述 与 联接 有 关 的 两 个 主题 。 第 一 ， 本 章 涵盖 了 数据 库 引擎 执行 联接 ( 嵌 套 循环 联接 、 合 并 
联接 和 散 列 联接 ) 时 所 使 用 的 方法 ， 并 讨论 了 什么 时 候 使 用 它们 是 合理 的 。 第 二 ， 本 章 涵盖 了 一 些 适 
用 于 查询 优化 器 改进 性 能 的 优化 技术 。 

现在 我 已 经 讨论 了 基础 的 访问 路 径 和 联接 方法 ,是 时 候 关 注 高 级 优化 技术 了 。 在 下 一 章 中 ,我 会 
讨论 物化 视图 、 结 果 缓 存 、 并 行 处 理 以 及 直接 路 径 插入 。 所 有 的 这 些 特 性 都 不 会 经 常用 到 ,但 是 正确 
使 用 它们 时 ， 能 够 带 来 极 大 的 性 能 改进 。 是 时 候 超 越 对 访问 和 联接 的 优化 了 。 


在 考虑 本 草 呈 现 的 高 级 优化 技术 之 前 ， 必 须 首先 完成 对 数据 访问 和 联接 的 优化 。 实际 上 ， 只 有 通 
过 其 他 方式 无 法 进行 优化 的 时 候 ， 才 会 考虑 使 用 此 处 描述 的 优化 技术 进一步 改进 性 能 。 换 句 话说， 应 
该 首先 修复 基础 问题 ， 然 后 ， 如 果 性 能 表现 仍然 不 可 接受 ， 可 以 考虑 特别 的 手段 。 

本 章 将 会 讲述 物化 视图 、 结 果 缓 存 、 并 行 处 理 、 直 接 路 径 插 入 、 行 预 取 和 数据 接口 等 技术 如 何 运 
作 ， 以 及 可 以 如 何 将 它们 用 于 改进 性 能 。 描 述 其 中 每 一 种 优化 技术 的 章节 都 会 按照 相同 的 方式 进行 组 
织 。 一 个 简短 的 介绍 ， 紧 接着 描述 这 种 技术 是 如 何 运 作 的 ， 然 后 是 应 该 在 什么 时 候 使 用 它 。 所 有 小 市 
都 以 对 一 些 常 见 的 陷阱 和 诸 误 的 讨论 作为 结尾 。 


注意 本 章 会 有 一 些 包 含 hint 的 SQL 语 名 作为 例子 向 你 展示 它们 的 使 用 方法 。 不 管 怎 样 ， 这 里 并 没有 
提供 真实 的 参考 和 完整 的 语法 。 可 以 在 Oracle Database SOL Language Reference 手 册 的 第 2 章 中 
找到 这 些 说 明 。 


本 章 会 展示 各 种 不 同 的 性 能 测试 的 结果 。 这 些 性 能 数据 只 是 试图 帮助 你 对 比 不 同类 型 的 处 理 方 
式 , 并 且 提 供 关 于 它们 的 影响 的 直观 感受 。 记 住 , 每 个 系统 和 每 个 应 用 程序 都 拥有 自己 的 特性 。 因此， 
使 用 每 种 技术 的 相关 性 可 能 会 有 很 大 不 同 ， 具体 取决 于 在 哪里 应 用 这 种 技术 。 


15.1 物化 视图 


视图 是 一 张 根据 在 创建 视图 时 指定 的 查询 语句 返回 结果 集 的 虚 表 。 每 次 访问 视图 时 ， 就 会 执行 查 
询 。 为 了 避免 在 每 次 访问 时 都 执行 查询 ， 可 以 将 查询 的 结果 集 存储 在 一 张 物 化 视图 中 。 换 名 话说 ， 物 
化 视图 仅仅 转换 并 复制 本 来 已 经 存储 在 别处 的 数据 。 


注意 ”物化 视图 也 可 用 于 分 布 式 环境 中 ， 以 便 在 数据 库 之 间 复 制 数据 。 这 种 用 法 本 书 不 作 介绍 


15.1.1 工作 原理 


接 下 来 的 小 节 会 描述 物化 视图 是 什么 以 及 它 是 如 何 运作 的 。 在 描述 完 物化 视图 的 基础 概念 之 后 ， 
会 详细 论述 查询 重 写 和 刷新 。 


15.1 物化 视图 $13 


1. 概念 
假设 必须 为 查询 ( 在 mv.sql 和 脚本 中 提供 ) 改 进 性 能 ,该 查询 基于 简单 的 模式 对 象 sh( Oracle Database 
Sample Schemas 手 册 完 整 描述 了 此 模式 对 象 ): 


SELECT p.prod category, c.country id， 
sum(quantity sold) AS quantity sold, 
sum(amount sold) AS amount sold 
FROM sales s, customers c¢, products p 
WHERE s.cust id = c.cust id 
AND s.prod id = p.prod id 
GROUP BY p.prod category, c.country_id 村 
ORDER BY p.prod category, c.country id 


如 果 按 照 第 10 章 和 第 13 章 中 描述 的 方法 和 规则 评估 该 执行 计划 的 效率 ， 你 会 发 现 一 切 正常 。 估 算 
很 完美 ， 不 同 访问 路 径 每 返回 一 行 的 逻辑 读 也 很 低 : 


Id | 0peration Name | Starts | E-Rows | A-Rows | Buffers | 
0 | SELECT STATEMENT | 4 | 81 3094 | 
1 | SORT GROUP BY | 1 | 68 81 3094 | 
* 2 | HASH JOIN 上 1 | 968 | 956 | 3094 | 
3 | TABLE ACCESS FULL PRODUCTS | 1 | 72 72 3 | 
4 VIEW | VW GBC 9 | 1 | 968 956 | 3091 | 
5 HASH GROUP BY | | | 968 956 | 3091 | 
* 6 HASH JOIN | 1 | 918K 918K| 3091 | 
7 TABLE ACCESS FULL | CUSTOMERS | 1| 55500 | 55500 1456 | 
8 PARTITION RANGE ALL| | :| 918K 918K| 1635 | 
9 | TABLE ACCESS FULL | SALES | 28 | 918K| 918K| 1635 | 


2 - access("ITEM 1"="P"."PROD ID") 
6 = Hecess("Ss" "CusT TD"s"C". "CUST I0") 
“问题 ”是 在 聚合 发 生 之 前 处 理 了 大 量 的 数据 。 无 法 只 通过 改变 某 条 访问 路 径 或 某 个 联接 方法 就 
能 使 性 能 有 所 增强 , 因为 它们 已 经 被 最 大 程度 地 优化 了 ; 换 句 话说 , 它们 的 全 部 潜力 已 经 被 开发 完毕 。 
是 时 候 应 用 一 种 高 级 优化 技术 了 。 我 们 来 根据 要 优化 的 查询 创建 一 张 物化 视图 。 
物化 视图 是 通过 CREATE MATERIALIZED VIEW 语 句 创 建 的 。 在 最 简单 的 情况 下 ， 需 要 指定 一 个 名 称 
和 构建 物化 视图 所 依据 的 查询 。 注 意 物 化 视图 依据 的 表 叫 作 基 表 ( 也 称 为 主 表 )。 下 面 的 SQL 语句 和 
图 15-1 对 此 进行 了 演示 ( 注意， 在 原始 查询 中 的 ORDER BY 子 句 被 省 略 了 ): 
CREATE MATERIALIZED VIEW sales mv 
AS 
SELECT p.prod category, c.country id, 
sum(quantity sold) AS quantity sold, 
sum(amount sold) AS amount sold 
FROM sales s, customers c¢, products p 
WHERE s.cust id = c.cust id 
AND s.prod id = p.prod id 
GROUP BY p.prod category, c.country id 
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CREATE MV SALES MV 


PRODUCTS 


图 15-1 物化 视图 的 创建 


注意 ” 当 你 基于 包含 ORDER BY 子 名 的 查询 创建 一 张 物化 视图 时 ， 只 有 在 物化 视图 创建 的 时 候 会 根据 
ORDER BY 子 名 对 数据 进行 排序 。 随 后 ， 在 刷新 期 间 ， 不 会 一 直 保持 这 个 排序 准则 。 这 是 因为 物 
化 视图 定义 之 中 不 会 包含 ORDER BY 子 句 ， 也 不 会 将 其 存储 到 数据 字典 中 。 


当 你 执行 上 面 的 SQL 语句 时 , 数据 库 引 擎 就 会 创建 一 张 物 化 视图 ( 其 只 是 数据 字典 中 的 一 个 对 象 ， 
换 句 话说 ， 它 只 是 元 数据 ) 和 一 张 容器 表 。 该 容器 表 是 一 张 拥 有 与 物化 视图 相同 名 称 的 普通 推 表 。 容 
器 表 用 于 存储 由 查询 返回 的 结果 集 。 

可 以 像 查 询 其 他 任何 表 那 样 查询 容器 表 。 下 面 的 SQL 语 句 展 示 这 样 的 一 个 例子 : 


SEEEGT * 
FROM sales mv 
ORDER BY prod category, country id 


0 | SELECT STATEMENT | | 1 | EM 
| 1 | SORT ORDER BY | | | 81 | 81 | 3 | 
2 | MAT VIEW ACCESS FULL| SALES MV | 1 | 3 | 


注意 逻辑 读 的 数值 ， 与 原始 查询 相 比 ， 从 3094 下 降 到 了 3。 还 要 注意 MAT_VIEW ACCESS FULL 这 个 访 
问 路 径 ， 它 清楚 地 阐述 了 对 物化 视图 的 访问 。 这 个 访问 路 径 操作 起 来 就 像 全 表 扫 描 一 样 。 这 仅仅 是 一 
种 用 于 方便 指明 使 用 了 物化 视图 的 命名 约定 。 而 实际 上 ， 这 两 种 访问 路 径 是 完全 一 样 的 。 

直接 引用 容器 表 始 终 是 一 个 可 选项 。 但 是 ， 如 果 想 在 不 修改 应 用 程序 执行 的 SQL 语句 的 情况 下 改 
进 它 的 性 能 ， 则 存在 第 二 种 有 效 的 途径 : 使 用 查询 重 写 。 


注意 ”查询 重 写 仅 在 企业 版 中 可 用 。 


查询 重 写 的 概念 相当 直 白 。 当 查询 优化 器 接收 到 需要 优化 的 查询 ， 它 可 以 决定 按照 原来 的 方式 使 
用 此 查询 ( 也 就 是 说 ， 不 使 用 查询 重 写 )， 或 者 它 也 可 以 选择 重 写 此 查询 ， 以 便 使 用 包含 执行 该 查询 


15.1 物化 视图 S13 


所 需 的 全 部 数据 或 部 分 数据 的 物化 视图 。 图 15-2 演 示 了 这 一 点 。 当 然 ， 这 个 决定 是 查询 优化 器 分 别 在 
使 用 和 不 使 用 查询 重 写 的 情况 下 ， 根 据 对 执行 计划 进行 的 成 本 估算 做 出 的 。 拥 有 更 低 成 本 的 执行 计划 
会 用 于 执行 该 查询 。rewrite 和 no_rewrite 这 两 个 hint 可 以 用 于 控制 查询 优化 器 的 决定 。 


SELECT .. 

FROM Sales， 
Customers, 
products 

WHERE .. 

GROUP BY .. 


没有 查询 重 写 


SELECT . 
FROM sales, 
Customers, SELECT . 
products FROM sales_mv 
WHERE ... 
GROUP BY .. 


SALES_MV 


CUSTOMERS 


PRODUCTS 


图 15-2 ”查询 优化 器 能 够 使 用 查询 重 写 来 自动 利用 物化 视图 


要 利用 查询 重 写 ， 必 须 在 两 个 级 别 上 启用 它 。 首 先 ， 必 须 将 query_rewrite_enabled 初 始 化 参数 设 
置 为 TRUE。 其 次 ， 必 须 为 物化 视图 启用 此 功能 。 下 面 的 SQL 语 句 展示 如 何 为 已 经 存在 的 物化 视图 启用 
查询 重 写 : 

ALTER MATERIALIZED VIEW sales mv ENABLE QUERY REWRITE 

如 果 启 用 了 查询 重 写 ， 那 么 一 旦 提交 了 原始 的 查询 ,查询 优化 器 就 会 将 此 物化 视图 作为 查询 重 写 
的 候选 项 。 在 此 情况 下 ,查询 优化 器 所 做 的 ， 实 际 上 是 重 写 查询 以 便 使 用 物化 视图 。 注 意 ，MAT_VIEW 
REWRITE ACCESS FULL 明 确 地 指出 了 查询 重 写 的 发 生 : 


SELECT p.prod category, c.country id, 
sum(quantity sold) AS quantity sold, 
sum(amount sold) AS amount sold 

FROM sales s, customers c¢, products p 

WHERE s.cust id = c.cust id 

AND s.prod id = p.prod id 

GROUP BY p.prod category, c.country id 

ORDER BY p.prod category, c.country id 
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0 | SELECT STATEMENT | | .| 六 
| 1 | SORT ORDER BY | | 1 | 81 | 81 | :对 | 
2 | MAT VIEW REWRITE ACCESS FULL| SALES MV | | 部 中 


概括 起 来 ， 通 过 查询 重 写 ,查询 优化 器 能 够 自动 使 用 包含 执行 一 个 查询 所 需 数据 的 物化 视图 。 打 
个 比方 ， 这 有 点 类 似 于 向 表 添加 索引 时 发 生 的 情况 。 你 〈 通常 ) 不 必修 改 SQL 语句 去 利用 它 。 多 亏 了 
数据 字典 , 查询 优化 器 知道 这 样 的 一 个 索引 存在 , 且 如 果 它 对 于 提升 一 条 SQL 语句 的 执行 效率 有 帮助 ， 
查询 优化 器 就 会 使 用 它 。 同 样 的 道理 也 适用 于 物化 视图 。 

当 通 过 DML 或 DDL 语 句 修改 基 表 时 , 物化 视图 ( 实际 上 是 容器 表 ) 可 能 会 包含 陈旧 的 数据 (“ 陈 
旧 ” 意 为 “ 老 的 "， 也 就 是 说 ， 如 果 此 时 基于 基 表 的 新 内 容 执行 查询 ， 数 据 已 经 不 再 等 价 于 物化 视 
图 查询 的 结果 集 )。 因 此 ， 数 据 库 引擎 会 停止 将 物化 视图 用 于 查询 重 写 。 出 于 这 个 原因 ， 如 图 15-3 
所 示 ， 在 修改 完 基 表 后 ， 必 须 执行 物化 视图 的 刷新 。 可 以 选择 什么 时 间 以 哪 种 方式 执行 物化 视图 的 
刷新 。 


SALES_MV 


PRODUCTS 


CUSTOMERS 


图 15-3 ”在 修改 完 基 表 之 后 ， 必 须要 刷新 物化 视图 


现在 我 已 经 介绍 了 基本 的 概念 ， 接 下 来 会 以 更 详细 的 方式 ,描述 一 下 在 创建 物化 视图 期 间 可 以 指 
定 哪些 参数 ， 以 及 查询 重 写 和 刷新 是 如 何 运 作 的 。 


2. 参数 

正如 上 节 中 所 述 ， 在 创建 一 张 物化 视图 时 可 以 不 指定 任何 参数 ， 不 过 也 可 以 完全 定制 它 的 创建 

口 可 以 指定 物理 属性 ， 比 如 分 区 、 压 缩 、 表 空间 等 ， 也 可 以 为 容器 表 指定 存储 参数 。 就 这 一 点 
而 言 ， 容 器 表 会 得 到 与 所 有 其 他 堆 表 一 样 的 对 待 。 鉴 于 此 ， 可 以 应 用 第 13 章 中 讨论 的 技术 来 
进一步 优化 数据 访问 。 
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口 创建 出 物化 视图 之 后 ， 就 会 执行 查询 ,然后 会 将 结果 集 插入 到 容器 表 中 。 这 是 因为 默认 使 用 
了 build immediate 参 数 。 还 存在 两 种 额外 的 可 选项 第 一 种 ， 通 过 指定 build deferred 参 数 将 
数据 的 插入 推迟 到 第 一 次 刷新 的 时 候 ; 第 二 种 ， 通 过 指定 prebuilt table 参 数 来 重用 一 张 已 经 


存在 的 表 作为 容器 表 。 
口 默认 情况 下 ， 查 询 重 写 是 禁用 的 。 要 启用 它 ， 必 须 指定 enable query rewrite 参 数 。 只 有 企业 
版 才 支 持 启用 查询 重 写 。 


口 为 改进 快速 刷新 〈 在 本 章 稍 后 讲述 ) 的 性 能 ， 默 认 会 在 容器 表 上 创建 一 个 索引 。 要 禁止 这 个 
索引 的 创建 ， 可 以 指定 using no index 人 参数 。 这 一 点 很 有 有 用， 例如， 为 了 避免 索引 维护 的 负载 ， 
而 且 这 个 负载 绝对 不 可 忽视 ， 当 然 前 提 是 你 永远 都 不 想 执行 快速 刷新 。 

下 面 的 SQL 语句 展示 了 基于 之 前 同一 个 查询 的 例子 ， 但 是 加 入 了 几 个 刚刚 描述 过 的 参数 : 

CREATE MATERIALIZED VIEW sales mv 

PARTITION BY HASH (country id) PARTITIONS 8 

TABLESPACE users 

BUILD IMMEDIATE 

USING NO INDEX 

ENABLE QUERY REWRITE 

AS 

SELECT p.prod category, c.country id, 

sum(quantity sold) AS quantity sold, 
sum(amount sold) AS amount sold 

FROM sales s, customers c, products p 

WHERE s.cust id = c.cust id 

AND s.prod id = p.prod id 

GROUP BY p.prod category, c.country id 


此 外 ， 也 可 以 指定 物化 视图 如 何 刷新 。“ 物 化 视图 刷新 ”一 节 提 供 了 关于 这 个 主题 的 详细 信息 。 


3. 查询 重 写 
无 论 何 时 一 个 SELECT 子 句 出 现在 SQL 语句 中 ,查询 优化 器 都 能 够 利用 查询 重 写 ， 或 者 ， 更 具体 一 
点 说 ， 在 以 下 几 种 情况 中 : 
口 SELECT ... FROM ... 
口 CREATE TABLE ... AS SELECT ..。 FROM ... 
口 INSERT INTO ..。 SELECT ... FROM ... 
口 子 查询 
此 外 ， 就 像 之 前 所 说 ， 只 有 在 满足 两 个 要 求 时 才 会 使 用 查询 重 写 。 第 一 ， 必 须 将 
query_rewrite_enabled 初 始 化 参数 设置 为 TRUE( 默认 值 ). 第 二 ,物化 视图 必须 使 用 enable query rewrite 
参数 创建 
一 旦 满足 这 些 要 求 , 每 次 查询 优化 吉 生 成 一 个 执行 计划 ， 它 都 会 查找 是 否 存在 一 张 包含 所 需 数据 
的 物化 视图 可 以 用 于 重 写 一 条 SQL 语句 。 为 了 这 个 目的 ， 它 使 用 以 下 三 种 方法 之 一 。 
口 全 文本 匹配 查询 重 写 ; 查询 语句 的 文本 传递 给 查询 优化 器 ， 用 来 与 每 个 可 用 的 物化 视图 的 查 
询 语句 中 的 文本 进行 比较 。 如 果 它 们 匹配 ， 显 然 该 物化 视图 包含 需要 的 数据 。 注 意 这 个 比较 
不 像 数 据 库 引 警 通常 所 用 的 比较 那么 严格 : 它 不 区 分 大 小 写 ( 除了 字面 值 ) 并 且 忽 略 空格 ( 例 
如 ， 新 行 和 制 表 符 ) 和 ORDER BY 子 句 ， 
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口 部 分 文本 匹配 查询 重 写 : 这 种 比较 类 似 于 全 文本 匹配 查询 重 写 中 使 用 的 比较 。 但 是 这 种 方式 
人 允许 在 SELECT 子 句 中 出 现 不 一 致 。 举 例 来 说 ,如 果 物 化 视图 存储 了 三 个 列 , 而 其 中 只 有 两 个 被 
需要 优化 的 查询 语句 引用 ， 则 物化 视图 包含 所 有 需要 的 数据 ， 因 此 就 可 以 使 用 查询 重 写 

口 通用 查询 重 写 : 为 了 找到 匹配 的 物化 视图 ， 通 用 查询 重 写 会 做 一 个 语义 分 析 。 出 于 这 个 目的 ， 
它 会 广泛 使 用 约束 和 维度 来 推断 基 表 中 数据 的 语义 关系 。 其 目的 是 ， 即 使 传递 给 查询 优化 吉 
的 查询 语句 与 匹配 的 物化 视图 的 查询 语句 有 很 大 不 同 ， 也 可 以 应 用 查询 重 写 。 事 实 上 ， 对 于 
设计 良好 的 物化 视图 来 说 ， 会 经 常用 于 重 写 许多 ( 而 且 还 可 能 是 不 同 的 ) SQL 语句 。 


查询 优化 器 使 用 数据 字典 中 存储 的 约束 来 推断 数据 关系 ， 以 最 大 程度 地 利用 通用 查询 重 写 。 有 
时 ， 其 他 一 些 非常 有 用 的 关系 ， 却 没有 被 约束 履 盖 到 ， 这 种 关系 存在 于 同一 张 表 的 列 之 间 ， 或 者 其 
至 是 不 同 的 表 之 间 。 对 于 非 规范 化 的 表 ( 例如 像 sh 模式 对 象 下 的 times 表 ) 尤为 如 此 。 为 了 向 查询 
优化 器 提供 这 样 的 信息 ， 可 以 使 用 维度 ( dimension )， 因 为 它 ， 可 以 使 用 层级 ( hierarchy ) 指定 1:n 
的 关系 以 及 可 以 使 用 属性 (attribute ) 指定 1:1 的 关系 。 层 级 和 属性 都 是 基于 级 别 ( level ) 的 ， 也 就 
是 ， 简 单 来 说 ， 一 张 表 中 的 列 。 下 面 的 SQL 语句 进行 了 演示 : 

CREATE DIMENSION times dim 

LEVEL day IS times.time id 

LEVEL month IS times.calendar month_ desc 

LEVEL quarter IS times.calendar quarter desc 

LEVEL year IS times.calendar year 

HIERARCHY cal rollup (day CHILD OF month CHILD OF quarter CHILD OF year) 

ATTRIBUTE day DETERMINES (day name, day_number, in month) 

ATTRIBUTE month DETERMINES (calendar month number, calendar month_name) 


ATTRIBUTE quarter DETERMINES (calendar quarter number) 
ATTRIBUTE year DETERMINES (days_in cal year) 


关于 维度 的 详细 信息 可 以 在 Oracle Database Data Warehousing Guide 手 册 中 找到 


可 以 很 迅速 地 应 用 全 文本 匹配 和 部 分 文本 匹配 查询 重 写 。 但 因为 它们 的 判定 是 基于 简单 的 文本 匹 
配 ，, 所 以 不 是 很 灵活 。 因 此 , 它们 只 能 重 写 有 限 数量 的 查询 。 比 较 起 来 , 通用 查询 重 写 则 要 强大 得 多 
不 足 之 处 是 应 用 这 种 技术 的 负载 也 要 高 很 多 。 出 于 这 个 原因 ， 查 询 优化 器 依据 复杂 性 的 递增 次 序 应 用 
这 些 方法 ( 从 而 分 解 开销 )， 直 到 找到 匹配 的 物化 视图 。 此 处 理 过 程 在 图 15-4 中 作 了 演示 。 

接 下 来 的 例子 来 自 mv_rewrite.sql 脚 本 ,展示 了 通用 查询 重 写 的 实战 操作 。 注 意 该 查询 类 似 于 上 
一 小 节 中 用 于 定义 sales_mv 物 化 视图 的 那个 查询 。 以 下 是 五 个 不 同 点 。 
口 SELECT 子 句 不 一 样 。 但 是 注意 ， 此 物化 视图 包含 所 有 必要 的 数据 。 
口 FROM 子 句 是 使 用 更 新 的 联接 语法 书写 的 〈 注 意 JOIN 和 ON 关键 字 )。 
口 GROUP BY 子 句 不 一 样 。 数 据 是 在 更 少 的 列 上 聚合 的 ( 与 物化 视图 的 定义 相 比 ， 缺 少 country_id 

列 )。 

口 指定 了 一 个 ORDER BY 子 句 。 
口 没有 引用 customers 表 。 然而 , 多 亏 sales 表 上 一 个 引用 了 customers 表 的 有 效 外 键 约束 ,查询 优 
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化 天 能 够 判断 出 省 略 这 个 联接 没有 什么 损失 〈 因此 ， 此 联接 无 法 消除 任何 数据 )。 


否 找 到 匹配 
物化 视图 ? 


无 法 执行 查询 重 写 是 该 
查询 重 写 查询 的 候选 方案 


图 15-4 查询 重 写 处 理 过 程 
不 管 这 些 区 别 ， 使 用 通用 查询 重 写 ， 查 询 优化 需 能 够 利用 sales_mv 物 化 视图 : 


SQL> SELECT upper(p.prod category) AS prod category, 
EF sum(s.amount sold) AS amount sold 
3 FROM sales s JOIN products p ON s.prod id = p.prod id 
4 GROUP BY p.prod category 
5 ORDER BY p.prod category; 
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0 | SELECT STATEMENT | | 
| 1 | SORT GROUP BY | | 
2 | MAT VIEW REWRITE ACCESS FULL| SALES MV | 


值得 注意 的 是 ， 在 默认 情况 下 ,查询 优 化 器 不 会 使 用 未 验证 的 约束 。 因 此 ， 如 果 存 在 未 验证 的 约 
束 ,查询 优化 器 无 法 使 用 通用 查询 重 写 。 因 此 ， 对 于 这 样 的 查询 来 说 ， 无 法 使 用 全 文本 匹配 查询 重 写 
和 部 分 文本 匹配 查询 重 写 ， 所 以 不 会 出 现 查询 重 写 。 下 面 的 例子 证 实 了 这 一 点 。 注 意 ， 除 了 FROM 子 句 
(但 是 ， 如 之 前 所 述 ， 这 个 细节 是 无 关 的 )， 这 里 使 用 的 是 与 上 一 个 例子 中 一 样 的 查询 。 然 而 ， 
sales_customer fk 约束 的 状态 发 生 了 改变 : 

SQL> ALTER TABLE sales MODIFY CONSTRAINT sales customer fk NOVALIDATE; 

SQL> SELECT upper(p.prod category) AS prod category, 

2 sum(s.amount sold) AS amount sold 
3 FROM sales s, pioducts p 
4 WHERE s.prod id = p.prod id 


5 GROUP BY p.prod category 
6 ORDER BY p.prod category; 


Id | Operation | Name 
0 | SELECT STATEMENT | 
1 SORT GROUP BY | 
i HASH JOIN 
3 VIEW | VW_GBC 5 
4 HASH GROUP BY | 
5 PARTITION RANGE ALL| 
6 TABLE ACCESS FULL | SALES 
中 TABLE ACCESS FULL | PRODUCTS 


2 - access("ITEM 1"="P"."PROD ID") 

尤其 是 对 于 数据 集 市 ， 使 用 那些 尽管 对 于 数据 库 引 擎 来 讲 是 未 验证 的 但 是 却 已 知 满足 数据 的 需求 
的 约束 很 常见 ， 这 要 归功 于 (仔细 地 ) 维护 表 数 据 的 方式 。 同 时 ， 拥 有 尽管 被 数据 库 引擎 认为 是 陈旧 
的 但 是 对 于 重 写 查 询 来 说 却 是 安全 的 物化 视图 也 很 常见 。 

要 在 这 样 的 情况 下 利用 通用 查询 重 写 ， 可 以 使 用 query rewrite integrity 初 始 化 参数 。 通 过 它 ， 
可 以 指定 是 否 仅 可 以 使 用 强制 的 约束 ( 因而 ， 对 数据 库 引 擎 来 说 是 验证 的 )， 以 及 是 否 使 用 包含 陈旧 
数据 的 物化 视图 。 可 以 将 该 参数 设置 为 以 下 三 个 值 。 

口 enforced: 仪 会 考虑 将 包含 最 新 数据 的 物化 视图 用 于 查询 重 写 。 注意 ,始终 会 认为 基于 外 部 表 

的 物化 视图 是 陈旧 的 。 此 外 ， 仅 验证 过 的 约束 用 于 通用 查询 重 写 。 这 是 默认 值 。 
口 trusted: 仅 会 考虑 将 包含 最 新 数据 的 物化 视图 用 于 查询 重 写 。 此 外 ,对 于 通用 查询 重 写 来 说 ， 
未 验证 过 且 使 用 rely 标 记 的 维度 和 约束 是 可 信 的 。 
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口 stale tolerated: 所 有 存在 的 物化 视图 ， 包括 那些 含有 陈旧 数据 的 ， 都 会 考虑 用 于 查询 重 写 。 
此 外 ， 对 于 通用 在 询 重 写 来 说 ， 未 验证 过 且 使 用 rely 标 记 的 维度 和 约束 是 可 信和 的 。 
下 面 的 例子 展示 如 何在 不 验证 约束 的 情况 下 使 用 通用 查询 重 写 。 正 如 展示 的 那样 ,会 对 约束 使 用 
rely 标 记 ， 并 且 会 将 完整 性 级 别 设置 为 trusted: 
SOL> ALTER TABLE sales MODIFY CONSTRAINT sales customer fk RELY; 


SOL> ALTER SESSION SET query rewrite integrity = trusted; 


SQL> SELECT upper(p.prod category) AS prod category, 
2 sum(s.amount sold) AS amount sold 
3 FROM sales s, products p 
4 WHERE s.prod id = p.prod id 
5 GROUP BY p.prod category 
6 ORDER BY p.prod category; 


0 | SELECT STATEMENT | | 
| 1 | SORT GROUP BY | | | 
2 | MAT VIEW REWRITE ACCESS FULL| SALES MV | 


如 果 因 为 其 中 一 个 SQL 语 句 没 有 使 用 查询 重 写 而 遇 到 麻烦 ， 而 且 你 不 知道 为 什么 ， 则 可 以 使 用 
dbms_mview 包 的 explain_rewrite 过 程 来 找 出 问题 所 在 。 下 面 的 PL/SQL 代 码 块 是 一 个 如 何 使 用 它 的 例 
子 。 注 意 ，query 参 数 指定 应 该 被 重 写 的 查询 ，mv 参 数 指 定 应 该 用 于 重 写 的 物化 视图 ， 而 statement_id 
参数 指定 一 个 任意 的 字符 串 用 于 识别 存储 在 输出 表 rewrite_table 中 的 信息 : 

SQOL> ALTER SESSION SET query rewrite integrity = enforced; 


SQL> DECLARE 
2 1 query CLOB := "SELECT upper(p.prod category) AS prod category， 
sum(s.amount sold) AS amount sold 
4 FROM sh.sales s, sh.products p 
5 WHERE s.prod id = p.prod id 
6 GROUP BY p.prod category 
7 ORDER BY p.prod category'; 
8 BEGIN 
9 DELETE rewrite table WHERE statement id = '42'; 
10 dbms mview.explain rewrite( 


11 query => 1 query, 

12 mv => 'sh.sales mv', 
13 statement id => '42" 

14 ); 

15 END; 

16 / 
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注意 ”rewrite table 表 默认 情况 下 并 不 存在 。 你 可 以 登录 到 用 于 分 析 的 模式 对 象 下 ， 通 过 执行 存储 
在 $0RACLE_HOME/rdbms/admin 目 录 下 的 utlxrw.sql 脚 本 来 创建 它 


该 过 程 的 输出 ,在 rewrite_table 表 中 提供 ,会 给 出 为 什么 查询 重 写 没 有 发 生 的 原因 ,输出 由 Oracle 
Database Error Messages 手册 中 记录 的 信息 组 成 。 以 下 是 之 前 的 分 析 的 输出 : 
SQL> SELECT message 


2 FROM rewrite table 
3 WHERE statement id = '42'; 


MESSAGE 


QSM-01150: query did not rewrite 

QSM-01284: materialized view SALES MV has an anchor table CUSTOMERS not found in query 

QSM-01052: referential integrity constraint on table, SALES, not VALID in ENFORCED integrity 

mode 

还 需要 注意 的 是 ,并非 所 有 查询 重 写 方法 都 可 以 应 用 到 所 有 物化 视图 上 。 某 些 物化 视图 只 支持 全 
文本 匹配 查询 重 写 。 其 他 的 一 些 只 支持 全 文本 匹配 和 部 分 文本 匹配 查询 重 写 。 总 的 来 说 ， 随 着 物化 视 
图 复杂 性 ( 例如 , 考虑 到 像 集合 运算 符 和 层次 查询 的 使 用 ) 的 增加 , 对 于 高 级 查询 重 写 的 支持 就 越 少 。 
限制 条 件 还 取决 于 Oracle 数 据 库 版 本 。 所 以 , 我 不 会 提供 一 个 受 支 持 查 询 重 写 的 清单 , 取而代之 的 是 ， 
我 会 向 你 展示 ， 对 于 一 个 给 定 的 例子 ， 如 何 找 出 哪些 查询 重 写 方法 是 受 支 持 的 。 为 了 演示 ,我 们 使 用 
下 面 的 SQL 语句 重新 创建 物化 视图 。 注意 , 与 之 前 的 例子 相 比 , 我 只 是 将 p.prod_status 添加 到 了 GROUP 
BY 子 句 中 (在 实践 中 ， 执 行 这 样 的 一 个 SQL 语句 通常 没什么 意义 ， 但 是 ， 很 快 你 就 会 发 现 ， 这 是 使 查 
询 重 写 部 分 失效 的 一 种 相对 简单 的 方式 ): 

CREATE MATERIALIZED VIEW sales_mv 

ENABLE QUERY REWRITE 

AS 

SELECT p.prod category, c.country id， 

sum(s.quantity sold) AS quantity sold, 
sum(s.amount sold) AS amount sold 

FROM sales s, customers c¢, products p 

WHERE Ss.cust id = c.cust id 

AND s.prod id = p.prod id 

GROUP BY p.prod category, c.country id, p.prod_status 

要 显示 一 个 物化 视图 支持 的 查询 重 写 方法 , 可 以 查询 下 面 例 子 中 所 示 的 user_mviews 视 图 (也 可 以 
使 用 相应 的 dba 、all 以 及 在 12.1 版 本 中 的 多 租户 环境 下 的 cdb 版 本 的 视图 )。 在 这 个 案例 中 ,根据 
rewrite enabled 列 ， 查 询 重 写 在 该 物化 视图 级 别 上 是 启用 的 ， 而 且 根 据 rewrite_capability 列 ， 只 有 
文本 匹配 查询 重 写 是 受 支 持 的 〈 换 句 话说， 不 支持 通用 查询 重 写 ): 


SQL> SELECT rewrite enabled, rewrite capability 
2 FROM user mviews 
3 WHERE mview name = 'SALES MV'; 


REWRITE ENABLED REWRITE CAPABILITY 


Y TEXTMATCH 
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注意 ，rewrite_capability 列 只 能 取 以 下 这 些 值 之 一 : none 、textmatch 或 general。 如 果 支 持 通 用 
查询 重 写 ( 因此 也 支持 其 他 两 种 方法 )， 则 user_mviews 视 图 提供 的 信息 就 是 够 了 。 然 而 ， 如 此 案例 中 
所 示 ， 如 果 显 示 的 是 值 textmatch， 则 还 至 少 需要 知道 另外 两 件 事情 。 第 一 , 在 这 两 种 文本 匹配 查询 重 
写 方法 中 , 哪 一 种 是 受 支 持 的 ?是 只 支持 全 文本 匹配 查询 重 写 ， 还 是 也 支持 部 分 文本 匹配 查询 重 写 ? 
第 二 ， 为 什么 不 支持 通用 查询 重 写 ? 

要 回答 这 些 问 题 ， 可 以 使 用 dbms_mview 包 中 的 explain_mview 过 程 ， 如 下 例 所 示 。 注 意 mv 参数 指定 
物化 视图 的 名 称 ，stmt_id 参 数 指定 一 个 任意 的 字符 串 用 于 识别 存储 在 输出 表 mv_capabilities table 
中 的 信息 : 


SQL> execute dbms mview.explain mview(mv => 'sales mv', stmt id => '42') 


注意 mv_capabilities_table 表 默认 情况 下 并 不 存在 。 可 以 通过 执行 在 $0RACLE_HOME/rdbms/admin 目 
录 下 存储 的 utlxmv.sql 脚 本， 在 要 使 用 它 的 模式 对 象 下 创建 此 表 。 


可 以 在 mv_capabilities_table 表 中 找到 该 过 程 的 输出 ， 该 输出 展示 了 sales_mv 物 化 视图 是 否 支 持 
这 三 种 查询 重 写 模式 ,如果 不支 持 , msgtxt 列 会 表明 某 个 具体 的 查询 重 写 模 式 因为 什么 原因 不 受 支 持 。 
在 这 个 案例 中 你 会 注意 到 , 问题 只 是 由 于 缺少 一 个 在 GROUP BY 子 句 中 引用 的 列 引起 的 ( 向 上 检查 此 SQL 
语句 ， 你 会 立即 发 现 引起 问题 的 列 : p.prod_status ): 
SQL> SELECT capability .name, possible, msgtxt 
2 FROM mv capabilities table 


3 WHERE statement id = '42" 
4 AND capability name IN ('REWRITE FULL TEXT MATCH', 


5 "REWRITE PARTIAL TEXT_MATCH', 

6 "REWRITE GENERAL'); 
CAPABILITY NAME POSSIBLE MSGTXT 
REWRITE_FULL TEXT MATCH YY 
REWRITE PARTIAL TEXT MATCH N grouping column omitted from SELECT list 
REWRITE GENERAL N grouping column omitted from SELECT list 
4. 刷新 


修改 了 某 张 表 之 后 ， 所 有 依赖 的 物化 视图 都 会 变 得 陈旧 。 因 此 ， 对 于 每 一 个 陈旧 的 物化 视图 ， 有 
必要 进行 刷新 。 可 以 在 创建 物化 视图 时 ， 指 定 刷新 如 何以 及 何 时 发 生 。 

要 指定 数据 库 引擎 如 何 执行 刷新 ， 可 以 从 以 下 方法 中 选择 。 

口 REFRESH COMPLETE: 容器 表 中 的 全 部 内 容 都 会 被 删除 ， 所 有 数据 都 会 从 基 表 重新 加 载 。 显 然 ， 
这 种 方法 总 是 受 支持 的 。 只 有 当 基 表 中 相当 大 的 一 部 分 被 修改 时 ， 或 由 于 物化 视图 的 复杂 性 
快速 刷新 不 可 用 时 ， 才 应 该 使 用 这 种 方法 。 

口 REFRESH FAST: 容器 表 中 的 内 容 被 重复 利用 ， 只 有 修改 的 部 分 会 被 传播 至 容器 表 。 如 果 基 表 中 
的 少量 数据 被 修改 ， 应 该 使 用 这 种 方法 。 仅 当 满 足 几 个 要 求 的 情况 下 这 种 方法 才 可 用 。 如 果 
其 中 的 一 个 没有 满足 ， 要 么 会 拒绝 将 REFRESH FAST 作 为 物化 视图 的 一 个 合法 参数 ， 要 么 会 引发 
一 个 错误 。 快 速 刷 新 和 PCT 刷 新 (一 种 特别 的 快速 刷新 )， 都 会 在 下 一 小 节 中 详细 介绍 。 
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口 REFRESH FORCE: 起 初 ， 尝 试 进行 快速 刷新 。 如 果 不 起 作用 ， 就 会 执行 完整 刷新 。 这 是 默认 的 
方法 s 
口 NEVER REFRESH: 物化 视图 从 不 进行 刷新 。 如 果 尝 试 进行 刷新 ,会 随 着 0RA-23538: cannot 
explicitly refresh a NEVER REFRESH materialized view 错 误 终 止 。 可 以 使 用 这 种 方法 来 确保 
永远 不 会 执行 刷新 。 
可 以 通过 以 下 两 种 方式 选择 物化 视图 刷新 出 现 的 时 间 点 。 
口 ON DEMAND: 物化 视图 只 有 在 被 明确 要 求 的 情况 下 刷新 ( 或 者 是 手动 或 者 是 通过 按 固 定 间 隅 运 
行 一 个 任务 )。 这 意味 着 在 从 基 表 发 生 修改 到 物化 视图 刷新 的 这 段 时 间 内 ， 物 化 视图 可 能 会 包 
含 陈旧 的 数据 。 
口 ON COMMIT: 物化 视图 会 在 修改 它 引 用 的 基 表 的 事务 结束 时 月 动 刷新 。 换 句 话 说， 就 其 他 的 会 
话 而 言 ， 物 化 视图 总 是 包含 最 新 的 数据 
可 以 组 合 这 些 选项 来 指定 物化 视图 如 何 刷 新 ， 以 及 何 时 进行 刷新 ， 并 且 在 CREATE MATERIALIZED 
VIEW 和 ALTER MATERIALIZED 语 名 中 都 可 以 使 用 它们 。 下 面 是 一 个 例子 : 
ALTER MATERIALIZED VIEW sales mv REFRESH FORCE ON DEMAND 
你 甚至 可 以 使 用 REFRESH COMPLETE ON COMMIT 选 项 创建 一 张 物 化 视图 。 然 而 ， 这 样 的 配置 好 像 不 太 
可 能 在 实践 中 有 什么 用 处 。 
要 显示 与 一 个 物化 视图 有 关 的 参数 ， 它 是 否 是 最 新 的 ， 还 有 上 一 次 刷新 是 如 何以 及 何 时 操作 的 ， 
可 以 查询 user_mviews 视 图 (也 可 以 使 用 相关 的 dba、all 以 及 在 12.1 版 本 中 的 多 租户 环境 下 的 cdb 版 本 ) 


SQL> SELECT refresh method, refresh mode, staleness, last refresh type, last refresh date 
2 FROM user mviews 
3 WHERE mview name = 'SALES MV'; 


REFRESH METHOD REFRESH MODE STALENESS LAST REFRESH TYPE LAST REFRESH DATE 


FORCE DEMAND FRESH COMPLETE 2013=12=10 15:5+ 

如 果 选 择 手 动 刷新 物化 视图 ， 可 以 调用 dbms_mview 包 中 的 以 下 过 程 之 一 。 

口 refresh: 此 过 程 刷新 通过 1ist 参 数 指定 为 逗号 分 隔 列表 的 物化 视图 。 例 如 ， 以 下 调用 会 刷新 
sh 用 户 拥有 的 sales_mv 和 cal _month_sales_mv 物 化 视图 : 
dbms_mview.refresh(list => "sh.sales mv,sh.cal month sales mv') 

口 refresh_all_mviews: 除了 那些 标记 为 永 不 刷新 的 物化 视图 以 外 ， 此 过 程 刷新 在 数据 库 中 存储 
的 所 有 物化 视图 。 输 出 参数 number of failures 返 回 在 处 理 期 间 出 现 的 失败 的 数量 : 
dbms mview.Tefresh all mviews(number of failures => :1) 

口 refresh_dependent: 此 过 程 刷 新 某 种 物化 视图 ， 这 种 物化 视图 依赖 通过 1ist 参 数 指定 为 逗号 
分 隔 列表 的 基 表 。 输 出 参数 number of failures 返 回 在 处 理 期 间 出 现 的 失败 的 数量 。 例 如 ， 以 
下 调用 会 根据 sh 用 户 拥有 的 sales 表 ， 刷 新 所 有 物化 视图 : 
dbms_mview.refresh dependent(number of failures => :r, list => 'sh.sales') 

所 有 这 些 过 程 还 支持 参数 method 和 atomic_refresh。 前 者 指定 如 何 完 成 刷新 (“ce” 代 表 完 全 刷新 ， 

'f” 代表 快速 刷新 ,，“p” 代表 PCT 刷 新 ,“?” 代 表 强 制 ), 后 者 指定 刷新 是 否 在 一 个 单独 的 事务 中 执行 
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如 果 将 atomic_refresh 参 数 设 置 为 FALSE ( 默认 值 是 TRUE )， 则 不 使 用 单独 的 事务 。 结 果 就 是 ， 对 于 完 
全 刷新 ， 物 化 视图 是 被 截断 而 不 是 被 删除 。 一 方面 ， 刷 新 更 快速 了 。 另 一 方面 ， 如 果 另 一 个 会 话 在 刷 
新 运行 期 间 查 询 物化 视图 ， 该 查询 可 能 会 返回 错误 的 结果 ( 没有 选中 任何 数据 )。 

此 外 ,从 12.1 版 本 开始 , 一 个 称 作 out_of_place 的 新 参数 可 用 了 。 如 果 将 这 个 out_of_place 参 数 设 
置 为 FALSE ( 默认 值 )， 刷 新 会 直接 在 与 物化 视图 关联 的 容器 表 上 执行 。 这 样 的 刷新 方式 对 于 访问 该 物 
化 视图 的 并 发 查询 来 讲 可 能 会 导致 一 些 问题 。 

如 果 将 out_of_place 设 置 为 TRUE， 那 么 刷新 会 在 男 一 张 表 的 帮助 下 执行 。 实 际 发 生 的 是 ， 会 创建 
出 男 外 一 张 容 右 表 ，, 会 通过 直接 路 径 插入 将 最 新 的 数据 插入 到 这 张 表 中 ， 新 的 容 右 表 与 旧 的 容器 表 进 
行 切 换 ， 最 终 丢 弃 掉 旧 的 容器 表 。 这 种 方法 ， 称 作 out-of-place 刷 新 ， 确 保 将 并 发 查询 访问 物化 视图 的 
影响 降 到 最 低 。 缺 点 是 在 刷新 期 间 ， 需 要 的 空间 加 倍 

一 旦 想 要 按 需 自动 化 一 个 刷新 ， 通 过 CREATE MATERIALIZED VIEW 和 和 ALTER MATERIALIZED VIEW， 都 可 
以 指定 第 一 次 刷新 的 时 间 (START WITH 子 句 ) 和 一 个 表达 式 来 评估 随后 的 刷新 的 时 间 ( NEXT 子 句 )。 例 
如 ， 使 用 下 面 的 SQL 语句 ， 会 将 刷新 安排 在 执行 SQL 语句 时 开始 ， 每 十 分 钟 进行 一 次 : 

ALTER MATERIALIZED VIEW sales mv 

REFRESH COMPLETE ON DEMAND 


START WITH sysdate 
NEXT sysdate+to dsinterval('0 00:10:00') 


为 调度 该 刷新 ， 会 自动 提交 一 个 基于 dbms job 包 的 后 台 任 务 。 注 意 dbms refresh 包 用 于 代替 
dbms_mview 包 : 
SOL> SELECT what, interval 
2 FROM user jobs; 


WHAT INTERVAL 


dbms_refresh.refresh('"CHRIS"."SALES MV"'); sysdate+to dsinterval('0 00:10:00') 


刷新 组 
dbms refresh 包 用 于 管理 刷新 组 (REFRESH GROUP ), 一 个 刷新 组 是 由 一 个 或 多 个 物化 视图 组 
成 的 一 个 简单 集合 。 通 过 dbms_refresh 包 中 的 刷新 过 程 执 行 的 刷新 是 在 一 个 单独 的 事务 中 执行 的 
(atomic Tefresh 被 设置 为 TRUE )，。， 如 果 需 要 保证 几 个 物化 视图 之 间 的 一 致 性 ， 那 么 这 种 行为 是 有 必 
要 的 。 这 还 意味 着 要 么 会 成 功 刷 新 包含 在 组 中 的 所 有 物化 视图 ， 要 么 会 回 滚 整 个 刷新 
EE CE 三 ES- 
@ 使 用 物化 视图 日 志 进 行 快速 刷新 
在 快速 刷新 期 间 , 会 重复 利用 容器 表 的 内 容 , 且 仪 会 将 修改 的 部 分 从 基 表 传播 至 容器 表 中 。 显然 ， 
数据 库 引 擎 只 有 在 知道 修改 的 部 分 时 才能 够 传播 它们 。 出 于 这 个 目的 ， 必 须 在 每 个 基 表 上 创建 一 个 物 
化 视图 日 志 (materialized view log ) 才能 启用 快速 刷新 ( 分 区 变化 跟踪 快速 刷新 会 在 下 一 小 节 中 讨论 ， 
是 现在 讨论 内 容 的 一 个 例外 ) 例如， 为 了 能 够 快速 刷新 ，sales_mv 物 化 视图 需要 sales 、customers 和 
products 表 上 的 物化 视图 日 志 。 
简 而 言 之 ,物化 视图 日 志 是 一 张 由 数据 库 引 擎 自动 维护 的 表 ， 用 于 跟踪 出 现在 基 表 上 的 变更 。 除 
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了 物化 视图 日 志 之 外 ,还 有 一 张 内 部 日 志 表 用 于 直接 路 径 插 入 。 你 不 需要 创建 它 ， 因 为 它 是 在 数据 库 
创建 的 时 候 自 动 安装 的 。 要 显示 它 的 内 容 ， 可 以 查询 all_sumdelta 视 图 。 

在 最 简单 的 案例 中 ， 可 以 使 用 像 下面 这 样 的 SQL 语 句 创 建物 化 视图 日 志 ( 这 个 例子 来 自 
mv_refresh log.sql 脚 本 ): 

SQL> CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID; 

SOL> CREATE MATERIALIZED VIEW LOG ON customers WITH ROWID; 


SQL> CREATE MATERIALIZED VIEW LOG ON products WITH ROWID; 

可 以 添加 WITH ROWID 子 名 来 指定 如 何 识 别 物化 视图 日 志 中 的 记录 ， 也 就 是 指定 如 何 识别 那些 被 每 
个 物化 视图 日 志 行 跟踪 的 修改 的 基 表 记录 。 也 可 以 创建 使 用 主键 或 对 象 ID 来 识别 修改 的 记录 的 物化 视 
图 日 志 。 但 是 ,针对 本 章 的 目的 , 记录 必须 通过 它们 的 rowid 进 行 识别 ( 其 他 的 方式 适合 在 分 布 式 环境 
中 使 用 物化 视图 的 时 候 使 用 )。 

就 像 物 化 视图 有 一 张 关联 的 容器 表 一 样 ， 每 个 物化 视图 日 志 也 有 一 张 关联 的 表 ,， 用 于 记录 对 基 表 
所 做 的 修改 。 下 面 的 查询 展示 如 何 显示 它 的 名 称 : 

SQL> SELECT master, log table 

2 FROM dba mview logs 


3 WHERE master IN ('SALES', 'CUSTOMERS', 'PRODUCTS') 
4 AND log owner = 'SH'; 


MASTER LOG TABLE 


CUSTOMERS MLOG$ CUSTOMERS 
PRODUCTS MLOG$ PRODUCTS 
SALES MLOG$_SALES 


对 于 某 些 物 化 视图 ， 这样 一 个 基本 的 物化 视图 日 志 并 不 足以 支持 快速 刷新 。 有 和 额外 的 要 求 需要 得 
到 满足 。 因 为 这 些 要 求 强烈 依赖 于 与 物化 视图 有 关 的 查询 以 及 Oracle 数 据 库 版 本 ， 我 不 会 提供 一 个 列 
表 ， 而 是 会 向 你 展示 对 于 一 个 给 定 的 案例 ， 如 何 找 出 这 些 要 求 是 什么 。 为 此 ,你 可 以 使 用 在 查找 有 哪 
些 支持 的 查询 重 写 模 式 时 使 用 的 相同 方法 ( 见 15.1.1 的 “查询 重 写 ”一 节 )。 换 句 话说 ， 可 以 使 用 
dbms_mview 包 中 的 explain_mview 过 程 ， 如 下 面 的 例子 展示 的 这 样 : 

SQL> execute dbms mview.explain mview(mv => 'sales mv', stmt id => '42') | 

该 过 程 的 输出 在 mv_capabilities_table 表 中 提供 。 要 查看 是 否 可 以 快速 刷新 物化 视图 ， 可 以 使 用 
类 似 下 面 这 样 的 查询 。 注意 在 输出 中 , 总 是 会 将 possible 这 一 列 设 置 为 N。 它 的 意思 是 没有 可 行 的 快速 
刷新 。 此 外 ，msgtxt 和 related text 列 表明 了 这 个 问题 的 原因 


SQL> SELECT capability name, possible, msgtxt, related text 
2 FROM mv capabilities table 
3 WHERE statement id = '42" 
4 AND capability name LIKE 'REFRESH FAST AFTER%'; 


CAPABILITY NAME POSSIBLE MSGTXT RELATED TEXT 


REFRESH_FAST_AFTER_INSERT N mv log must have new values SH.PRODUCTS 
REFRESH FAST AFTER INSERT N mv log does not have all necess SH.PRODUCTS 
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ary columns 


REFRESH_FAST_AFTER_INSERT mv log must have new values SH.CUSTOMERS 
REFRESH_FAST_AFTER INSERT mv log does not have all necess SH.CUSTOMERS 
ary columns 
REFRESH FAST AFTER INSERT N mv log must have new values SH.SALES 
REFRESH_ FAST AFTER INSERT N mv log does not have all necess SH.SALES 
ary columns 
REFRESH _ FAST AFTER ONETAB DML N SUM(expr) without COUNT(expr) AMOUNT_ SOLD 
REFRESH_FAST AFTER ONETAB DML N SUM(expr) without COUNT(expr) QUANTITY SOLD 
REFRESH_FAST AFTER ONETAB DML N see the reason why REFRESH FAST 
_AFTER INSERT is disabled 
REFRESH_FAST _AFTER ONETAB DML N COUNT(*) is not present in the 


select list 

SUM(expr) without COUNT(expr) 

mv log does not have sequence # SH.PRODUCTS 
mv log does not have sequence # SH.CUSTOMERS 
mv log does not have sequence # SH.SALES 

see the reason why REFRESH FAST 

_AFTER ONETAB DML is disabled 


其 中 的 一 些 问题 和 物化 视图 日 志 有 关 ， 其 他 的 则 与 物化 视图 有 关 。 简 而 言 之 ， 数 据 库 引 警 需要 更 
多 的 信息 来 执行 快速 刷新 。 

为 了 解决 与 物化 视图 日 志 有 关 的 问题 , 必须 在 CREATE MATERIALIZED VIEW L0G 语 句 中 添加 一 些 选项 。 

口 对 于 “myv log does not have all necessary columns” 问 题 ， 必 须 指定 每 个 被 物化 视图 引用 的 列 都 
存储 在 物化 视图 日 志 中 。 

口 对 于 “mv log must have new values” 问 题 ， 必 须 添加 INCLUDING NEW VALUES 子 句 。 通 过 这 个 选 
项 ， 物 化 视图 日 志 会 在 执行 更 新 被 时 将 旧 值 和 新 值 ( 默认 情况 下 仅 会 存储 旧 值 ) 都 存储 起 来 
(也 就 是 说 ， 会 有 两 条 记录 写 人 到 物化 视图 日 志 中 )。 

口 对 于 “mv log does not have sequence” 问 题 ， 则 有 必要 添加 SEOUENCE 子 句 。 通 过 这 个 选项 ， 会 
有 一 个 序列 号 与 物化 视图 日 志 中 存储 的 每 一 行 数据 相关 联 。 

F 面 是 重新 定义 的 物化 视图 日 志 : 


SQL> CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, SEQUENCE 
2 (cust id，prod id, quantity sold, amount sold) INCLUDING NEW VALUES; 


REFRESH_FAST_AFTER_ONETAB_DML 
REFRESH_FAST AFTER_ANY_DML 
REFRESH_FAST_AFTER_ANY_DML 
REFRESH_FAST_AFTER_ANY_DML 
REFRESH_FAST_AFTER_ANY_DML 


芝 更 2 


SQL> CREATE MATERIALIZED VIEW LOG ON customers WITH ROWID, SEQUENCE 
2 (cust id, country id) INCLUDING NEW VALUES; 


SOL> CREATE MATERIALIZED VIEW LOG ON products WITH ROWID, SEQUENCE 
2 (prod id, prod category) INCLUDING NEW VALUES; 


TIMESTAMP 与 COMMIT SCN-BASED 物 化 视图 日 志 


从 12.1 版 本 开始 ， 有 两 种 类 型 的 物化 视图 日 志 : 基于 时 间 蕉 的 和 基于 提交 SCN 号 的 。 因 为 基于 
时 间 蕉 的 物化 视图 日 志 是 在 11.1.0.7 及 之 前 的 版 本 中 唯一 存在 的 形式 ,所 以 在 后 续 的 版 本 中 也 是 默认 
使 用 它们 。 要 使 用 新 的 类 型 ， 必 须 在 创建 物化 视图 日 志 时 指定 COMMIT SCN 子 铅 。 下 面 的 SQL 语句 展 
二 可 一 从 说 也 
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CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, COMMIT SCN, SEQUENCE (cust id, prod id, 
duantity sold，amount sold) INCLUDING NEW VALUES 


尽管 从 用 户 的 角度 出 发 ,这 两 种 类 型 之 间 没 有 区 别 ， 但 是 物化 视图 日 志 所 使 用 的 快速 刷新 的 算 
法 ， 在 基于 提交 SCN 号 时 会 带 来 更 好 的 性 能 。 
注意 基于 提交 SCN 号 的 物化 视图 日 志 默 认 没 有 启用 ， 因 为 它们 受到 一 些 限 制 。 例 如， 带 有 LOB 


列 的 表 是 不 受 支持 的 。 
EE ER 


为 了 解决 与 物化 视图 相关 的 问题 ， 必 须 将 一 些 基 于 count 函 数 的 新 列 添加 到 与 物化 视图 关联 的 查 
询 中 。 下 面 的 SQL 语句 展示 了 包含 新 列 的 定义 : 


CREATE MATERIALIZED VIEW sales mv 

REFRESH FORCE ON DEMAND 

AS 

SELECT p.prod category, c.country id， 
sum(s.quantity sold) AS quantity sold, 
sum(s.amount sold) AS amount sold, 
count(*) AS count_ star, 
count(s.quantity sold) AS count quantity_sold, 
count(s.amount_ sold) AS count amount_ sold 

FROM sales s, customers c¢, products p 

WHERE s.cust id = c.cust id 

AND s.prod id = p.prod id 

GROUP BY p.prod category, c.country id 


在 重新 定义 完 物 化 视图 日 志和 物化 视图 之 后 , 在 使 用 explain_mview 过 程 的 进一步 分 析 中 , 结果 显 
示 快 速 刷新 在 所 有 情况 下 都 是 可 行 的 (possible 列 都 设置 为 Y )。 那 么 我 们 通过 向 两 张 表 中 插入 数据 ， 
然后 执行 快速 刷新 来 测试 一 下 刷新 到 底 有 多 快 : 


S0L> INSERT INTO products 

SELECT 619, prod name, prod desc, prod subcategory, prod subcategory id, 
3 prod _ subcategory desc, prod category, prod category id, 

4 prod category desc, prod weight class, prod unit of measure, 

5 prod pack size, supplier id, prod status, prod list price, 

6 prod min price, prod total, prod total id, prod src id, 
7 

8 

9 


LD 


prod eff from, prod eff to, prod valid 
FROM products 
WHERE prod id = 136; 


SQL> INSERT INTO sales 
2 SELECT 619, cust id, time id, channel id, promo id, quantity sold, amount sold 
3 FROM sales 
4 WHERE prod id = 136; 

SQL> COMMIT; 


SQL> execute dbms mview.refresh(list => 'sh.sales mv', method => 'f') 


Elapsed: 00:00:00.12 


在 本 例 中 ， 快 速 刷新 持续 了 0.12 秒 钟 。 如 果 不 满意 快速 刷新 的 性 能 ， 应 该 使 用 SQL 跟 踪 调 查 为 何 
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它 花费 了 这 么 久 。 然 后 ,通过 应 用 第 13 章 中 描述 的 技巧 ， 你 可 能 能 够 通过 添加 索引 ( 在 主 表 上 ,在 物 
化 视图 上 ， 或 甚至 有 时 候 在 物化 视图 日 志 上 添加 ) 或 给 一 个 物理 段 分 区 来 加 速 查 询 。 


提示 “根据 你 使 用 的 版 本 以 及 你 遇 到 问题 的 物化 视图 的 类 型 ， 有 几 个 未 公开 的 参数 有 可 能 会 影响 性 
能 。 讨 论 这 些 参 数 超出 了 本 书 的 范围 。 如 果 有 关于 快速 刷新 的 性 能 问题 ， 建 议 查看 一 下 Oracle 
Support 文 档 Master Note for Materialized Fiew ( 1353040.1 )， 特 别 是 “Performance Issues with 
MVIEW” 一 节 


@ 使 用 分 区 变化 跟踪 进行 快速 刷新 

存储 历史 数据 的 表 经 常会 按照 日 、 星 期 或 年 进行 范围 分 区 。 换 句 话 说 , 分 区 是 基于 存储 时 间 信 息 
的 列 。 因 此 ， 新 分 区 的 加 入 ， 数 据 加 载 到 分 区 中 ， 以 及 丢弃 旧 分 区 ( 通常 只 会 保持 特定 数量 的 分 区 在 
线 ) 都 是 有 规律 地 发 生 的 。 在 执行 完 这 些 操作 后 ， 所 有 依赖 的 物化 视图 都 是 陈旧 的 ， 并 且 因此 应 该 进 
行 刷 新 

问题 是 使 用 物化 视图 日 志 的 快速 刷新 ( 如 上 一 小 节 所 描述 )， 无 法 在 类 似 ADD PARTITION 或 DROP 
PARTITION 这 样 的 分 区 管理 操作 之 后 执行 。 如 果 尝 试 这 样 的 刷新 ， 数 据 库 引 擎 会 引发 一 个 ORA-32313: 
REFRESH FAST of <mview> unsupported after PMops 错 误 。 当 然 了 ， 完 全 刷新 总 是 可 以 执行 的 。 然 而 ， 
如 果 有 很 多 的 分 区 而 且 只 有 其 中 一 个 或 两 个 被 修改 了 ， 完 全 刷新 的 时 间 可 能 是 不 可 接受 的 。 

要 解决 这 个 问题 ， 可 以 使 用 基于 分 区 变化 跟踪 ( partition change tracking，PCT ) 的 快速 刷新 。 这 
样 做 可 行 是 因为 , 数据 库 引 擎 不 仅仅 在 表 级 别 而 且 在 分 区 级 别 也 有 能 力 跟 踪 数 据 是 否 陈 旧 。, 换 句 话说 ， 
对 于 所 有 没有 修改 过 的 分 区 ， 可 以 跳 过 刷新 。 要 使 用 这 种 刷新 方法 ， 物 化 视图 必须 满足 一 些 要 求 。 基 
本 上 就 是 ,数据库 引擎 必须 能 够 将 物化 视图 中 存储 的 数据 映射 到 基 表 的 分 区 上 。 如 果 物 化 视图 包含 以 
下 各 项 之 一 ， 这 就 是 可 行 的 : 

口 分 区 键 

口 Rowid 

口 分 区 标记 ( partition marker ) 

口 联接 相关 ( Join-dependent ) 表达 式 

前 两 个 是 什么 应 该 是 显而易见 的 ; 我 们 来 看 一 下 第 三 个 和 第 四 个 的 例子 。 一 个 分 区 标记 只 不 过 是 
由 dbms_mview 包 中 的 pmarker 函 数 生成 的 一 个 分 区 标识 符 ( 实际 上 , 它 是 与 分 区 段 有 关 的 数据 对 象 ID )。 
要 生成 分 区 标记 , 此 函数 使 用 rowid 作 为 一 个 参数 传递 进来 。 下 面 的 例子 来 自 mv_refresh_pct.sql 肢 本， 
展示 了 如 何 创建 包含 分 区 标记 的 物化 视图 ( 注意 ，sales 表 是 分 区 的 ): 


CREATE MATERIALIZED VIEW sales mv 

REFRESH FORCE ON DEMAND 

AS 

SELECT p.prod category, c.country id, 
sum(quantity sold) AS quantity sold, 
sum(amount sold) AS amount sold, 
count(*) AS count star, 
count(quantity sold) AS count quantity sold, 
count(amount sold) AS count amount sold, 
dbms_mview.pmarker(s.rowid) AS pmarker 
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FROM sales s, customers ¢, products p 

WHERE s.cust id = c.cust id 

AND s.prod id = p.prod id 

CROUP BY p.prod category, c.country id, dbms_ mview.pmarker(s.rowid) 


注意 ”因为 每 一 行 都 要 调用 pmarker 函 数 ， 不 要 低估 此 调用 所 需 的 时 间 。 在 我 的 系统 上 ， 创 建 包含 分 
区 标记 的 物化 视图 花费 的 时 间 比 不 使 用 分 区 标记 的 时 间 长 2.5 信 


当 物 化 视图 在 SELECT 子 句 中 引用 的 其 中 一 个 列 ， 来 自 一 张 通过 基于 分 区 键 进行 等 值 谓 词 联接 的 表 
时 ,该 物化 视图 包含 一 个 联接 相关 表达 式 。 在 本 节 使 用 的 例子 中 , 它 的 意思 是 不 仅 会 将 与 tmes 表 相关 
的 等 值 联接 (s.time id = t.time id ) 加 入 到 物化 视图 中 ， 而 且 会 将 times 表 的 其 中 一 个 列 
(t.fiscal year ) 添加 到 SELECT 和 GROUP BY 子 句 中 。 下 面 是 一 个 例子 : 


CREATE MATERIALIZED VIEW sales mv 

REFRESH FORCE ON DEMAND 

AS 

SELECT p.prod category, c.country id, t.fiscal year, 
sum(quantity sold) AS quantity sold, 
sum(amount sold) AS amount sold, 
count(*) AS count star, 
count(quantity sold) AS count quantity sold, 
count(amount sold) AS count amount sold 

FROM sales s, customers c, products p, times t 

WHERE s.cust id = c.cust id 

AND s.prod id = p.prod id 

AND s.time id = t.time id 

GROUP BY p.prod category, c.country id, t. 机 


使 用 了 分 区 标记 或 分 区 相关 表达 式 后 ,基于 dbms _mview 包 中 explain_mview 函 数 的 一 个 分 析 告 诉 我 
们 基于 分 区 变化 跟踪 的 快速 刷新 是 可 行 的 。 然 而 ， 它 只 对 于 在 sales 表 上 执行 的 修改 是 可 行 的 ; 


SQL> SELECT capability name, possible, msgtxt, related text 
2 FROM mv_capabilities table 
3 WHERE statement id = 
4 AND capability name IN ('PCT TABLE','REFRESH FAST PCT'); 


CAPABILITY NAME POSSIBLE MSGTXT RELATED TEXT 
PCT_TABLE 和 SALES 
PCT_TABLE N relation is not a partitioned table CUSTOMERS 
PCT_TABLE N relation is not a partitioned table PRODUCTS 
REFRESH_FAST PCT Y 


15.1.2” 何 时 使 用 


物化 视图 是 元 余 的 访问 结构 。 与 所 有 宛 余 访 问 结构 一 样 ， 它 们 对 于 提高 访问 数据 的 效率 有 帮助 ， 
但 是 它们 会 为 了 保持 最 新 而 增加 负载 。 如 果 将 物化 视图 与 索引 进行 对 比 ， 物 化 视图 带 来 的 效率 提升 和 
负载 可 能 都 会 比索 引 高 出 很 多 。 很 明显 ， 这 两 个 概念 则 在 解决 不 同 的 问题 。 简 而 言 之 ， 只 有 在 加 速 数 
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据 访 问 的 正面 作用 超过 了 管理 元 余数 据 副 本 《〈 例如 索引 ) 的 负面 作用 时 ， 才 应 该 使 用 物化 视图 。 
总 的 来 说 ， 我 觉得 物化 视图 有 以 下 两 个 作用 。 
口 在 逻辑 读数 量 和 返回 记录 数量 之 间 的 比值 非常 高 的 时 候 ， 用 于 改进 大 型 聚合 或 联接 操作 的 
性 能 。 
口 在 全 表 扫 描 和 索引 扫描 效率 都 不 高 的 时 候 ， 用 于 改进 单 表 访问 的 性 能 。 基 本 上 ， 如 果 这 些 访 
问 拥有 平均 选择 率 则 可 能 会 需要 分 区 ， 但 是 如 果 无 法 利用 分 区 ( 第 13 章 讨论 过 什么 时 候 这 是 
不 可 行 的 )， 则 物化 视图 可 能 会 有 所 帮助 。 
通常 可 以 在 数据 仓库 中 使 用 物化 视图 构建 存储 聚合 。 这 样 做 有 两 个 原因 。 第 一 ,数据 大 部 分 是 只 
读 的 ; 因此 ， 当 数据 库 仅 致力 于 修改 表 的 时 候 ， 可 以 将 刷新 物化 视图 的 负载 最 小 化 并 通过 时 间 窗 口 隔 
离开 来 。 第 二 ,在 这 样 的 环境 中 ,性 能 提升 可 能 是 巨大 的 。 事 实 上 ， 不 使 用 物化 视图 时 ， 经 常会 发 现 
基于 大 型 聚合 或 联接 的 查询 会 请 求 无 法 接受 的 需要 处 理 的 资源 总 量 。 
即使 数据 仓库 是 使 用 物化 视图 的 主要 环境 ， 我 也 曾经 在 OLTP 系 统 上 成 功 地 实施 过 它们 。 这 可 能 
对 那些 经 常 被 查询 而 相对 而 言 却 很 少 进行 修改 的 表 有 利 。 在 这 样 的 环境 中 刷新 物化 视图 时 ， 经 常 使 用 
on commit 快 速 刷 新 ， 以 便 保 证 亚 秒 级 刷新 并 时 刻 保持 最 新 的 物化 视图 。 


15.1.3 ”陷阱 和 廖 误 ; 


因为 快速 刷新 并 非 总 是 比 完全 刷新 快 , 所 以 并 非 在 所 有 的 情况 下 都 应 该 使 用 快速 刷新 。 具体 来 讲 ， 
比如 在 基 表 中 有 大 量 数据 被 修改 的 情况 。 此 外 , 也 不 要 低估 在 修改 基 表 的 同时 维护 物化 视图 日 志 带 来 
的 负载 。 因 此 ， 应 该 仔细 评估 使 用 快速 刷新 的 利弊 。 

当 创建 物化 视图 日 志 时 ， 对 于 逗号 的 使 用 必须 非常 小 心 。 看 出 下 面 的 SQL 语句 哪里 出 问题 了 么 ? 

SQL> CREATE MATERIALIZED VIEW LOG ON products WITH ROWID, SEQUENCE, 


2 (prod id, prod _ category) INCLUDING NEW VALUES; 
CREATE MATERIALIZED VIEW LOG ON products WITH ROWID, SEQUENCE, 


米 


ERROR at line 1: 
ORA-12026: invalid filter column detected 


问题 出 在 关键 字 SEQUENCE 和 过 滤 清 单 〈 换 句 话说， 括号 之 间 的 列 清单 ) 之 间 的 逗号 。 如 果 出 现 了 
逗号 ， 则 隐 仿 PRIMARY KEY 选 项 ， 而 在 本 例 中 不 可 以 指定 该 选项 ， 因 为 主键 (prod id 列 ) 已 经 在 过 滤 
清单 中 了 。 下 面 是 正确 的 SQL 语句 。 注 意 ， 只 是 移 除了 逗号 : 

SQL> CREATE MATERIALIZED VIEW LOG ON products WITH ROWID, SEQUENCE 

2 (prod id, prod category) INCLUDING NEW VALUES; 


Materialized view log created. 


15.2 ”结果 缓存 


缓存 是 计算 机 系统 改进 性 能 所 用 的 最 常见 技术 之 一 。 无 论 硬件 还 是 软件 都 对 其 有 着 广泛 的 应 用 。 
Oracle 数 据 库 也 不 例外 。 举例 来 说 ，Oracle 数 据 库 在 缓冲 区 缓存 中 缓存 数据 文件 块 , 在 数据 字典 缓存 中 
缓存 数据 字典 信息 ， 以 及 在 库 缓 存 中 缓存 游标 。 从 11.1 版 本 开始 ， 结 果 缓 存 也 可 用 了 。 
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注意 ”结果 缓存 仅 在 企业 版 中 可 用 。 


15.2.1 工作 原理 


Oracle 数 据 库 提供 以 下 三 种 类 型 的 结果 缓存 。 

口 服务 器 结果 缓存 ( 也 称 作 查 询 结果 缓存 ) 是 存储 查询 结果 集 的 服务 器 端 缓存 。 

口 PL/SQL 函 数 结果 缓存 是 存储 PL/SQL 函 数 返回 值 的 服务 器 端 缓存 。 

口 客户 端 结果 缓存 是 存储 查询 结果 集 的 客户 端 缓存 。 

接 下 来 的 小 节 描述 这 些 缓存 如 何 运 作 ， 以 及 要 利用 它们 你 必须 要 做 哪些 事情 。 记 住 ， 默 认 情况 下 
并 不 会 启用 结果 缓存 。 


1. 服务 器 结果 缓存 
服务 器 结果 缓存 可 以 用 于 避免 查询 和 某 些 子 查 询 ( 在 NITH 子 句 中 定义 的 子 查 询 和 在 FROM 子 句 中 定 
义 的 内 联 视图 ) 的 重复 执行 。 简 言 之 ， 当 第 一 次 执行 某 个 查询 时 ， 它 的 结果 集 就 会 存储 在 共享 池 中 ， 
然后 ， 对 于 后 续 执 行 的 相同 查询 来 说 ， 结 果 集 直接 由 结果 缓存 提供 而 不 需要 重新 计算 。 注 意 如 果 认 
为 两 个 查询 是 相等 的 ， 那 么 可 以 使 用 相同 的 缓存 结果 集 ， 前 提 是 它们 拥有 相同 的 文本 ( 但 是 在 空格 
和 大 小 写 方面 的 区 别 是 允许 的 )。 此外， 如 果 有 绑 定 变量 出 现 ， 它 们 的 值 必须 完全 相同 。 这 是 有 必要 
的 ， 因 为 很 明显 绑 定 变 量 是 传递 给 查询 的 输入 参数 ， 所 以 对 于 不 同 的 绑 定 变量 值 ， 结 果 集 通常 也 会 
不 同 。 还 要 注意 因 结果 缓存 存储 在 共享 池 中 ， 所 以 连接 到 一 个 给 定数 据 库 实 例 的 所 有 会 话 共享 相同 
的 缓存 条 目 。 
为 了 向 你 展示 一 个 例子 (来自 rc_query_hint.sq1 脚 本 )， 我 们 来 执行 已 经 在 物化 视图 一 节 中 使 用 
了 两 次 的 查询 ( 注意 ， 在 查询 中 指定 了 result cache hint 来 启用 结果 缓存 ): 
SQL> SELECT /*+ result cache */ 
2 p.prod category, c.country id, 
3 sum(s.quantity sold) AS quantity sold, 
4 sum(s.amount sold) AS amount sold 
5 FROM sales s, customers c¢, products p 
6 WHERE Ss.cust id = c.cust id 
7 AND s.prod id = p.prod id 
8 GROUP BY p.prod category, c.country id 
9 ORDER BY p.prod category, c.country id; 


Elapsed: 00:00:01.25 


Id | Operation Name | Starts | A-Rows 
0 | SELECT STATEMENT | 1 81 

1 | RESULT CACHE 089x05gkvfuxq7wqg06u9zozkb | 1 | 81 

| 2 SORT GROUP BY | 1 81 
村 久 HASH JOIN | | 和 956 
| 4 TABLE ACCESS FULL PRODUCTS | 六 72 
5 | VIEW VW_GBC 9 | 1 956 

6 HASH GROUP BY | 1 956 
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发 - 地 HASH JOIN | 1 | 918Kk| 
EE TABLE ACCESS FULL | CUSTOMERS | 1 | 55500 | 
| PARTITION RANGE ALL | | 1| 918K| 
| ww | TABLE ACCESS FULL | SALES | 28 | 918K| 


3 - access("ITEM 1"="P"."PROD ID") 
7 - access("S"."CUST ID"="C". "CUST ID") 

第 一 次 执行 花费 了 1.25 秒 。 注 意 在 执行 计划 中 ，RESULT CACHE 操 作 已 确认 为 这 个 查询 启用 了 结果 
缓存 。 然 而 ， 执 行 计划 的 Starts 列 清楚 地 显示 出 所 有 操作 都 被 执行 了 至 少 一 次 。 所 有 操作 的 执行 都 是 
有 必要 的 ， 因 为 这 是 该 查询 的 第 一 次 执行 ， 也 就 是 说 ， 结 果 缓 存 还 没有 包含 相应 的 结果 集 。 

第 二 次 执行 变 快 了 (0.16 秒 ): 


SOL> SELECT /*+ result cache */ 

p.prod category, c.country id, 

3 sum(s.quantity sold) AS quantity sold, 
4 sum(s.amount sold) AS amount sold 

5 FROM sales s, customers c¢, products p 

6 WHERE s.cust id = c.cust id 
区 
8 
9 


和) 


AND s.prod id = p.prod id 
GROUP BY p.prod category, c.country_id 
ORDER BY p.prod category, c.country id; 


Elapsed: 00:00:00.16 


| Id Operation | Name | Starts | A-Rows | 
0 | SELEET STATEMENT | | | 8 1 
1 | RESULT CACHE | 089x05gkvfuxq7wqg06u9zozkb | 1 | 81 

[ 名 SORT GROUP BY | | 0 | 0 | 

* 3 HASH JOIN | | 0 | 0 | 
4 TABLE ACCESS FULL | PRODUCTS | 0 | 0 | 
5 VIEW | WW _GBC 9 | 0 | 0 | 
6 HASH GROUP BY | | 0 | 0 | 

汪汪 HASH JOIN | | 0 | 0 | 
8 TABLE ACCESS FULL | CUSTOMERS | 0 | 0 | 
9 PARTITION RANGE ALL| | 0 | 0 | 
10 TABLE ACCESS FULL | SALES | oa 0 | 


3 - access("ITEM 1"="p"."PROD ID") 
7 = access("S"."CUST ID"="C","CUST ID"Y 


这 一 次 ， 执 行 计划 中 的 Starts 列 显示 除了 RESULT CACHE 之 外 没有 执行 其 他 操作 。 注 意 第 10 章 中 提 
到 过 的 一 个 行 源 操作 可 以 完全 避免 调用 它 的 子 操作 ， 因 为 它 不 需要 子 操作 来 完成 它 的 工作 ,这 正 是 那 
些 案例 之 一 。 换 句 话 说， 该 查询 的 结果 集 直 接 从 结果 缓存 中 提供 。 

在 这 个 执行 计划 中 , 有 意思 的 是 , 我 们 注意 到 名 称 缓存 ID ( cache ID ) 与 RESULT CACHE 操 作 相 关联 。 
如 果 你 知道 此 缓存 ID ， 可 以 查询 v$result_ cache objects 视 图 来 显示 关于 缓存 数据 的 信息 。 下 面 的 查 
询 显示 缓存 的 结果 集 已 经 发 布 了 ( 也 就 是 说 ， 可 以 使 用 了 )， 还 显示 了 结果 缓存 是 何 时 创建 的 ， 构 建 
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它 花费 了 多 长 时 间 (以 百 分 之 一 秒 为 单位 )， 在 其 中 存储 了 多 少 记录 ， 以 及 它 被 引用 了 多 少 次 : 


SQL> SELECT status, creation timestamp, build time, row count, scan count 
2 FROM v$result cache objects 
3 WHERE cache id = “089x05gkvfuxq7wqg06u9zOzkb ; 


STATUS CREATION_TIMESTAMP BUILD TIME ROW COUNT SCAN COUNT 


published 2013-12-11 10:27 95 81 2 

提供 结果 缓存 信息 的 视图 还 有 v$result cache dependency 、v$result cache memory 和 
v$result cache statistics, 

从 11.2 版 本 开始 ,指定 result_cache hint 并 非 启 用 结果 缓存 唯一 可 用 的 方式 。 男 一 种 技术 是 在 表 级 
别 指定 ， 通 过 将 result_cache 子 句 设置 为 force， 引 用 该 表 的 所 有 查询 的 所 有 结果 集 都 必须 被 缓存 ( 除 
非 指 定 no_result_cache hint )。 注 意 result_cache 子 句 的 默认 模式 是 default。 这 个 技术 对 于 包含 主要 
用 于 读 取 的 数据 的 表 尤 其 有 用 。 事 实 上 ， 多 亏 这 种 技术 ， 才 可 以 不 必 更 改 应 用 程序 就 利用 结果 缓存 。 
你 需要 做 的 全 部 事情 就 是 指定 在 表 级 别 上 启用 结果 缓存 。 

注意 在 一 个 单独 的 查询 中 引用 多 个 表 时 ， 所 有 这 些 表 都 必须 已 经 通过 result_ cache 子 句 设置 为 
force 来 启用 结果 缓存 。 下 面 的 SQL 语句 ， 是 来 自 rc_query_table.sql 脚 本 的 一 段 摘 录 ， 展 示 如 何 为 本 
节 示 例 中 查询 所 使 用 的 三 张 表 启用 结果 绥 存 : 

SOL> ALTER TABLE sales RESULT_CACHE (MODE FORCE); 


SQL> ALTER TABLE customers RESULT CACHE (MODE FORCE); 


SQL》 ALTER TABLE products RESULT_CACHE (MODE FORCE); 

为 保证 结果 集 的 一 致 性 ( 也 就 是 说 ， 无 论 结果 集 是 从 结果 缓存 中 直接 提供 ， 还 是 由 数据 库 的 内 容 
计算 得 来 ， 都 应 该 是 一 样 的 )， 每 当 查 询 所 引用 的 表 中 发 生 了 某 些 变化 ， 依 赖 它 的 缓存 条 目 就 失效 了 
( 很 快 就 会 讨论 一 个 使 用 远程 对 象 的 例外 )。 即 使 没有 真正 的 变化 发 生 ， 也 是 这 样 。 例 如 ， 即 使 是 一 条 
SELECT FOR UPDATE， 马 上 跟随 着 一 个 COMMIT， 也 会 导致 依赖 于 SELECT 的 表 的 缓存 条 目 失 效 。 这 意味 着 
当 一 张 表 卷 入 到 一 个 事务 中 时 ,依赖 这 张 表 的 缓存 条 目 就 会 失效 ,而 不 是 在 缓存 条 目 依 赖 的 数据 发 生 
变化 时 失效 。 换 句 话 说， 依赖 性 不 是 细 粒 度 跟踪 的 : 与 修改 的 记录 是 否 会 影响 缓存 结果 无 关 

下 面 是 控制 服务 器 结果 缓存 的 动态 初始 化 参数 。 

口 result_cache_mode 指 定 在 什么 样 的 情况 下 使 用 结果 缓存 。 既 可 以 将 它 设置 为 nanual ( 也 就 是 默 

认 设 置 ), 也 可 以 将 它 设置 为 force。 使 用 manual, 仅 当 通过 result_ cache 这 个 hint 或 result cache 
子 句 启用 它 的 情况 下 ， 结 果 缓 存 才 会 起 作用 。 使 用 force ， 结 果 缓 存 会 用 于 除 指定 了 
no_result_cache hint 以 外 的 所 有 查询 ,因为 在 大 多 数 情形 下 你 都 是 只 想 为 有 限 数量 的 查询 启用 
结果 缓存 ， 我 建议 你 保持 这 个 初始 化 参数 的 默认 值 即 可 。 

口 result_cache_max_size 指 定 可 以 用 于 结果 缓存 的 共享 池内 存 总 量 ( 按 字 节 )。 如 果 将 它 设 置 为 

0， 则 该 特性 被 完全 禁用 。 其 默认 值 ， 比 0 要 大 一 些 ， 是 根据 共享 池 的 大 小 得 来 的 。 该 内 存 分 
配 是 动态 的 ， 因 此 这 个 初始 化 参数 指定 的 只 是 上 限 。 可 以 通过 类 似 下 面 这 样 的 查询 显示 当前 
分 配 的 内 存 : 
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SQL> SELECT name, sum(bytes) 
2 FROM v$sgastat 
3 WHERE name LIKE 'Result Cache%” 
4 GROUP BY rollup(name); 


NAME SUM(BYTES) 
Result Cache 145928 
Result Cache: Bloom Fltr 2048 
Result Cache: Cache Mgr 208 
Result Cache: Memory Mgr 200 
Result Cache: State Objs 2896 

151280 


口 result_cache_max_result 指 定 结果 缓存 中 任何 一 个 单独 的 条 目 可 以 使 用 的 result_cache max size 
的 总 量 ( 按 百分比 )。 默认 值 是 5， 允许 的 值 范围 是 0~100。 
口 fesult_ cache_ remote _expiration 指 定 基 于 远程 对 象 的 结果 缓存 中 条 目的 有 效 时 间 长 度 ( 按 分 
钟 计 )。 这 样 做 是 有 必要 的 ， 因 为 基于 远程 对 象 的 条 目的 失效 操作 并 不 是 在 远程 对 象 发 生变 化 
时 执行 的 。 反 而 ， 条 目 会 在 达到 初始 化 参数 指定 的 有 效 时 长 时 失效 。 默 认 值 是 0(， 也 就 意味 着 
基于 远程 对 象 查询 的 缓存 是 被 禁用 的 。 
result cache max ea cache_max_Fesult 初 始 化 参数 仅 可 以 在 系统 级 别 上 进行 更 改 。 此 
外 ,在 12.1 多 租户 环境 下 ， 它 们 仅 可 以 在 CDB 级 别 上 进行 设置 。 另 外 两 个 参数 ，result_ cache _mode 和 
et ion， 还 可 以 在 会 话 级 别 上 进行 修改 。 


警告 ”将 result cache remote expiration 初 始 化 参数 设置 为 一 个 大 于 0 的 值 会 导致 过 期 的 结果 ， 因 
此 ， 只 有 在 完全 理解 并 接受 这 样 做 的 影响 的 情况 下 ， 才 应 该 使 用 大 于 0 的 值 


在 结果 绥 存 的 使 用 方面 ， 有 几 个 尽管 很 明显 但 还 是 要 提 一 下 的 限制 。 
口 引用 具有 不 确定 性 的 SQL 函数 、 序 列 以 及 临时 表 的 查询 不 会 被 缓存 。 
口 违反 读 一 致 性 的 查询 不 会 被 缓存 。 举 例 来 说 ,在 引用 的 表 上 拥有 未 决 事务 的 情况 下 ， 由 一 个 
会 话 创建 的 结果 集 无 法 被 缓存 。 
口 引用 数据 字典 视图 的 查询 不 会 被 缓存 


DBMS_RESULT_CACHE 。 


可 以 使 用 dbms result cache 包 来 管理 结果 缓存 。 为 此 ， 它 提供 了 以 下 子 程序 。 

口 pypass 在 会 话 或 系统 级 别 上 临时 禁用 (或 启用 ) 结果 缓存 

口 flush 从 结果 缓存 中 移 除 所 有 对 象 

口 invalidate 使 所 有 依赖 于 某 个 给 定数 据 库 对 象 的 结果 集 无 效 。 

D invalidate_object 使 一 个 单独 的 缓存 条 目 无 效 

口 memory_report 生 成 一 份 内 存 使 用 的 报告 

口 status 显 示 结 果 缓 存 的 状态 
NE 
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2. PL/SQL 函 数 结果 缓存 
PL/SQL 画 数 结果 缓存 类 似 于 服务 器 结果 缓存 ， 但 是 它 支 持 PL/SQL 函 数 。 它 也 与 服务 器 结果 缓存 
一 样 共享 相同 的 内 存 结构 。 它 的 用 途 是 在 结果 缓存 中 存储 PL/SQL 函 数 返回 的 值 ( 而 且 只 有 函数 的 返回 
值 ， 结 果 绥 存 不 能 用 于 输出 参数 )， 显然 ， 拥 有 不 同 输入 值 的 函数 被 缓存 在 各 自 的 缓存 条 目 中 。 下 面 
的 例子 ,是 一 段 由 rc_plsql.sql 脚 本 生成 的 输出 的 摘录 ， 展示 了 一 个 启用 结果 缓存 的 函数 。 要 启用 它 ， 
需要 指定 RESULT_CACHE 子 句 : 
SQL> CREATE OR REPLACE FUNCTION f(p IN NUMBER) 
2 RETURN NUMBER 
3 RESULT_CACHE 
4 IS 
5 1 ret NUMBER; 
6 BEGIN 
7 SELECT count(*) INTO 1 ret 
8 FROM t 
9 WHERE id = p; 
10 RETURN 1 _ Yet; 
11 END; 
退 过 


在 下 面 的 例子 中 ， 该 函数 在 没有 利用 结果 缓存 〈 通 过 过 程 bypass， 绥 存 被 临时 禁用 了 ) 的 情况 下 
被 调用 了 10 000 次 。 执 行 持续 了 大 约 4 秒 钟 : 
SQL> execute dbms result cache.bypass(bypass_mode => TRUE, session => TRUE) 


SOL> SELECT count(f(1)) FROM t; 


COUNT(F(1)) 


Elapsed: 00:00:04.02 

现在 ,我 们 再 次 调用 该 函数 10 000 次 ， 但 是 这 一 次 是 在 结果 缓存 启用 的 情况 下 。 执 行 只 持续 了 大 
约 百 分 之 三 秒 : 

SQL> execute dbms _ result cache.bypass(bypass mode => FALSE, session => TRUE) 


SQL> SELECT count(f(1)) FROM t; 


COUNT(F(1)) 


Elapsed: 00:00:00.03 


从 11.2 版 本 开始 ,数据库 引擎 会 自动 发 现 一 个 函数 依赖 了 哪些 表 。 基 于 此 信息 ,一 旦 某 个 事务 修 
改 了 结果 缓存 条 目 依 赖 的 一 张 表 的 任何 数据 ， 则 可 以 自动 使 该 结果 缓存 条 目 失 效 。 
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警告 ”在 11.1 版 本 中 ， 只 有 在 函数 级 别 指定 了 RELIES ON 子 句 ， 结 果 缓存 条 目 才 会 失效 。RELIES ON 子 
多 的 用 途 是 指定 函数 返回 值 依 赖 哪些 表 。 这 个 信息 对 于 缓存 条 目的 失效 十 分 重要 。 如 果 没 有 
指定 它 ， 或 包含 错误 的 信息 ， 当 函数 依赖 的 对 象 发 生 修改 的 时 候 就 不 会 有 条 目 失效 。 因 此 ， 
就 会 出 现 过 期 的 结 


PL/SQL 琐 数 结果 缓存 的 使 用 方面 有 一 些 限制 。 该 结果 缓存 无 法 用 于 以 下 这 些 机 数 。 
口 带 有 OUT 或 IN 0UT 参 数 的 函数 
口 使 用 调用 者 的 权限 定义 的 函数 (此 限制 从 12.1 版 本 开始 不 再 存在 ) 
口 管道 化 表 栅 数 
口 在 匿名 块 中 定义 的 函数 
口 函数 的 IN 参数 或 返回 值 是 以 下 类 型 的 : LOB 、REF CURSOR、 对 象 和 记录 
此 外 ， 注意 未 处 理 的 异常 不 会 存储 在 结果 缓存 中 。 也 就 是 说 ， 如 果 一 个 函数 引发 一 个 异常 ， 并且. 
该 异常 被 传播 至 调用 者 ， 那 么 同一 个 函数 的 下 一 次 调用 还 会 被 再 次 执行 。 


3. 客户 端 结果 缓存 

客户 端 结 果 缓 在 是 一 种 客户 端 缓存 ,存储 由 某 些 特定 应 用 程序 执行 查询 所 产生 的 结果 集 ， 这 些 应 
用 程序 使 用 的 Oracle 数 据 库 驱动 构建 于 OCI 库 之 上 ( 例如 JDBC OCI、ODPNET、OCCI 和 ODBC )。 它 
的 用 途 和 工作 方式 类 似 于 服务 器 结果 缓存 。 特 别 是 ， 启 用 它们 的 可 选 技术 ( result_cache hint 、 
RESULT_CACHE 子 名 以 及 result-cache_mode 初 始 化 参数 ) 是 相同 的 。 唯 一 额外 的 需求 是 ， 利 用 客户 端 语 
句 缓 存 ( client-side statement caching， 参 见 第 12 章 ) 的 专 有 SQL 语 句 可 以 启用 客户 端 结果 缓存 。 与 服 
务 右 端 实 现 相 比 ， 有 两 点 重要 的 区 别 。 第 一 ， 它 避免 了 需要 在 客户 端 /服务 屁 之 间 往 返 执 行 SQL 语 句 。 
这 是 一 个 很 大 的 优势 。 第 二 ， 失 效 是 基于 一 种 轮 询 机 制 ， 因 此 ， 一 致 性 无 法 得 到 保证 。 这 又 是 一 个 很 
大 的 劣势 - 


注意 ”在 12.1 版 本 的 多 租户 环境 下 ， 客 户 端 结果 缓存 不 受 支 持 。 


为 实现 轮 询 ， 客 户 端 不 得 不 定期 执行 数据 库 调 用 ， 以 向 数据 库 引 擎 检查 它 的 其 中 某 个 缓存 结果 集 
是 否 已 经 失效 。 为 最 小 化 与 轮 询 相关 的 负载 ， 每 次 当 客 户 端 因为 其 他 什么 原因 执行 数据 库 调 用 时 ， 它 
也 会 同时 检查 缓存 结果 集 的 有 效 性 。 通 过 这 种 方式 ， 对 于 那些 有 规律 地 执行 “定期 ”数据 库 调 用 的 客 
户 端 来 说 ， 就 避免 了 专门 用 于 检查 缓存 结果 集 有 效 性 的 数据 库 调 用 。 
即使 这 是 一 种 客户 端 缓存 ， 你 也 不 得 不 在 服务 器 端 启 用 它 。 注 意 即 使 服务 器 端 缓存 被 禁用 了 ( 换 
名 话说 ， 如 果 将 result_cache_max_size 初 始 化 参数 设置 为 0 )， 客 户 端 缓存 也 会 继续 工作 。 以 下 是 控制 
客户 端 结果 缓存 的 初始 化 参数 。 
口 client result_ cache size 指定 每 个 客户 端 进程 可 以 用 于 结果 缓存 的 最 大 内 存 总 量 〈 按 字 节 
计 )。 如 果 将 它 设 置 为 0， 也 就 是 默认 值 ， 则 会 禁用 该 特性 。 这 个 初始 化 参数 是 静态 参数 ， 并 
且 仅 可 以 在 系统 级 别 上 进行 设置 。 因 此 ， 要 修改 它 ， 必 须 重 启 数据 库 实例 。 
口 client result_cache_1ag 指 定 两 次 数据 库 调 用 之 间 的 最 长 时 间 间 隔 ( 按 毫秒 计 )。 也 就 是 说 ， 
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它 指定 过 期 的 结果 集 可 以 在 客户 端 缓 存 中 保留 多 长 时 间 。 默 认 值 是 3000。 这 个 初始 化 参数 是 
静态 参数 ， 并 且 仅 可 以 在 系统 级 别 上 进行 设置 。 因 此 ， 要 修改 它 ， 必 须 重 启 数据 库 实例 。 
除了 服务 器 端 配置 之 外 ， 还 可 以 在 客户 端的 sqlnet.ora 文 件 中 指定 以 下 参数 。 

口 oci result_cache_ max _ size 攻 盖 使 用 client _ result_ cache size 初始化 参数 指定 的 服务 器 端 配 
置 。 注 意 ， 不 管 怎样 ， 如 果 客 户 端 结果 缓存 在 服务 器 端 被 禁用 了 ， 则 这 个 参数 也 无 能 为 力 。 
口 oci_ result_cache_max_Trset_size 指 定 任何 一 个 单独 的 结果 集 可 以 使 用 的 最 大 内 存 总 量 ( 按 字 

节 计 )。 
口 oci_result_cache_max_rset_rows 指 定 任何 一 个 单独 的 结果 集 可 以 存储 的 最 大 行 数 。 


15.2.2” 何 时 使 用 


如 果 正 在 处 理 一 个 因为 应 用 程序 不 断 重复 执行 相同 的 操作 而 引起 的 性 能 问题 , 你 必须 减少 执行 的 
频率 或 者 减少 操作 的 响应 时 间 。 理 想 情 况 下 ， 两 者 都 应 该 做 。 然 而 ， 有 时 (例如 ， 当 应 用 程序 的 代码 
无 法 修改 ) 你 只 能 实现 后 者 。 为 减少 响应 时 间 ， 应 该 首先 尝试 使 用 第 13 章 和 第 14 章 中 呈现 的 技术 。 如 
果 这 样 还 不 够 ,只 有 那 时 候 才 应 该 考虑 高 级 优化 技术 ,例如 结果 缓存 。 基 本 上 来 说 ,结果 缓存 在 两 个 
给 定 条 件 下 是 高 效 的 。 第 一 ， 相 同 的 数据 查询 远 比 修改 要 频繁 。 第 二 ， 有 足够 的 内 存 来 缓存 结果 集 。 

在 大 多 数 情况 中 ， 你 不 应 该 为 所 有 的 查询 启用 结果 缓存 。 事 实 上 ， 大 多 数 时 候 ， 只 有 特定 的 查询 
能 够 从 结果 缓存 中 获 益 。 对 于 除了 特殊 案例 以 外 的 其 他 查询 ,结果 缓存 管理 就 只 是 纯粹 的 负载 ,， 并 有 
可 能 使 缓存 压力 过 大 。 还 要 牢记 服务 器 端 缓存 由 所 有 会 话 共享 ， 所 以 它们 的 访问 是 同步 的 (它们 可 以 
像 其 他 任何 共享 资源 那样 变 成 序列 化 的 )。 因 此 ， 你 应 该 只 为 需要 结果 缓存 的 查询 、 子 查询 以 及 表 来 
启用 该 项 技术 。 换 名 话说 ， 只 有 在 当 结 果 缓存 对 于 改进 性 能 是 真正 有 必要 的 情况 下 ， 才 应 该 有 选择 性 
地 启用 它 。 . 

服务 器 结果 缓存 不 会 完全 避免 执行 一 个 查询 的 负载 。 这 意味 着 如 果 一 个 查询 在 没有 使 用 结果 缓存 
的 情况 下 已 经 实现 了 相对 较 少 的 逻辑 读 ( 并 且 没 有 物理 读 )， 那 么 使 用 结果 缓存 的 时 候 也 不 会 快 到 哪 
去 。 记 住 , 缓冲 区 缓存 和 结果 缓存 都 存储 在 相同 的 共享 内 存 中 。 

PL/SQL 函 数 结果 缓存 对 于 经 常 从 SQL 语 句 中 调用 的 函数 尤其 有 用 ,事实 上 ,对 于 这 样 的 函数 来 讲 ， 
即使 输入 参数 只 在 一 少 部 分 记录 上 有 所 不 同 ， 对 每 一 行 处 理 的 或 返回 的 数据 都 执行 调用 也 很 常见 。 不 
管 怎样 ， 经 常 在 PL/SQL 中 被 调用 的 函数 也 可 以 从 结果 缓存 中 获 益 。 

因为 一 致 性 的 问题 ， 应 该 仅 将 客户 端 结果 缓存 用 于 只 读 表 或 只 读 为 主 的 表 。 

最 后 ， 记 住 你 可 以 同时 利用 服务 器 端 和 客户 端 结果 缓存 。 然 而 ， 对 于 由 客户 端 执行 的 查询 ， 你 不 
能 选择 绕 过 客户 端 结果 缓存 而 只 使 用 服务 器 结果 缓存 。 也 就 是 说 ， 两 种 结果 缓存 都 会 被 使 用 。 


15.2.3 ”陷阱 和 廖 误 


正如 在 之 前 的 章节 中 指出 的 那样 ， 结 果 的 一 致 性 在 以 下 情况 下 是 无 法 确保 的 : 

口 将 result_cache_remote_expiration 初 始 化 参数 设置 为 一 个 大 于 0 的 值 ， 并 且 通 过 数据 库 链接 
(dblink ) 执行 查询 时 ; 

口 在 11.1 版 本 中 ,定义 了 没有 指定 (或 错误 指定 ) RELIES_ON 子 句 的 PL/SQL 本 数 时 ; 

口 使 用 了 客户 端 结果 缓存 时 。 
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因此 ， 遇 到 这 样 的 情况 ， 最 好 避免 使 用 结果 缓存 ， 除 非 你 完全 理解 并 接受 以 上 每 种 情况 可 能 带 来 
的 影响 。 

对 于 引用 了 非 确定 性 PL/SQL 函数 的 查询 , 或 者 对 于 类 似 NLS 参 数 和 上 下 文 环 境 这 样 的 会 话 级 设置 
敏感 的 函数 来 说 ， 如 果 缓 存 了 它们 的 结果 ， 则 它们 可 能 不 会 像 你 预期 的 那样 工作 。 问 题 是 在 默认 情况 
下 ， 数 据 库 引 擎 认为 那些 函数 是 确定 性 的 ， 所 以 最 后 可 能 就 会 生成 错误 的 结果 。 我 在 
rc_query_nondet.sql 脚 本 中 提供 了 几 个 例子 。 下 面 的 例子 就 是 其 中 之 一 ( 注意 第 二 个 查询 是 如 何 返 回 
错误 结果 的 ): 

SOL> CREATE OR REPLACE FUNCTION f RETURN VARCHAR2 

2 IS 

3 1 ret VARCHAR2(64); 

4 BEGIN 

5 SELECT /*+ no result cache */ to char(sysdate) INTO 1 ret FROM dual; 

6 RETURN 1 ret; 

7 END f; 

8 / 


SQL> ALTER SESSION SET nls date format = 'YYYY-MM-DD HH24:MI:SS'; 
SQL> SELECT /*+ result cache */ f() FROM dual; 

2014-01-06 18:08:05 

SOL> ALTER SESSION SET nls date format = 'YYYY-MM-DD'; 

SOL> SELECT /*+ result cache */ f() FROM dual; 


2014-01-06 18:08:05 

为 避免 这 个 问题 , 从 11.2.0.4 版 本 开始 , 可 以 将 未 公开 初始 化 参数 _result_cache_deterministic plsql 
设置 为 TRUE。 有 关 详 细 信息 ， 请 参考 Oracle Support 文 档 Bug 14320218 Wrong results with query results 
cache using PL/SOL function ( 14320218.8 )。 


15.3 并行 处 理 
向 数据 库 引 擎 提交 一 条 SQL 语 句 时 ， 默 认 情 况 下 它 是 由 一 个 单独 的 服务 进程 串 行 执行 的 。 因 此 ， 


即使 运行 数据 库 引 擎 的 服务 器 有 多 个 CPU 内 核 ， 你 的 SQL 语 句 也 只 能 运行 在 其 中 一 个 CPU 内 核 上 。 并 
行 处 理 的 作用 是 将 一 条 单独 SQL 语 句 的 执行 过 程 分 布 在 多 个 CPU 内 核 上 。 


注意 ”并行 处 理 仅 在 企业 版 中 可 用 ，, 
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15.3.1 工作 原理 


在 描述 如 何 通 过 并 行 方式 执行 查询 、DML 语 句 和 DDL 语 句 的 具体 细节 之 前 , 有 必要 先 理解 并 行 处 
理 的 基础 ， 如 何 配 置 一 个 数据 库 实例 以 便利 用 并 行 处 理 ， 以 及 如 何 控 制 并 行 度 。 


1. 基础 

不 使 用 并 行 处 理 时 ,一 条 SQL 语 句 是 由 一 个 单独 的 服务 进程 串 行 执 行 的 ,也 就 是 在 一 个 单独 的 CPU 
内 核 上 运行 。 这 意味 着 能 够 用 于 执行 一 条 SQL 语 句 的 资源 总 量 受 到 单一 CPU 内 核能 够 提供 的 处 理 能 力 
限制 。 举 例 来 说 ， 如 图 15-5 所 示 ， 如 果 SQL 语 句 执 行 的 扫描 整个 段 的 数据 访问 操作 ( 如 果 大 部 分 数据 
是 从 磁盘 读 取 ， 则 可 能 是 磁盘 1/O 密 集 型 操作 ) 与 磁盘 IO 子 系统 能 够 传递 的 总 吞吐 量 无 关 ， 则 响应 时 
间 会 受到 一 个 单独 的 CPU 内 核 所 能 够 使 用 的 带宽 限制 。 因 为 CPU 内 核 与 磁盘 之 间 的 数据 访问 路 径 的 硬 
件 限 制 ， 带 宽 一 定 是 受 限 的 ， 而 且 当 执行 是 串 行 的 时 候 还 无 法 完全 利用 这 部 分 带宽 : 当 服 务 进 程 获取 
CPU， 按 照 定义 我 们 知道 它 此 时 没有 访问 磁盘 ( 异步 IO 操作 对 于 这 里 来 说 是 一 个 例外 )， 因 此 无 法 利 
用 磁盘 I/O 子 系统 能 够 传递 的 全 部 吞吐 量 . 


图 15-5 。 串 行 执行 的 SQL 语句 由 单独 的 一 个 服务 进程 处 理 


下 面 的 SQL 语句 及 其 关联 的 执行 计划 展示 了 图 15-5 所 示 处 理 过 程 的 一 个 例子 : 
SELECT * FROM t 


| 0 | SELECT STATEMENT | | 
| 1| TABLE ACCESS FULLI T | 


并 行 处 理 的 目的 是 将 一 个 大 的 任务 拆 分 成 几 个 小 的 子 任务 。 如 果 有 一 条 并 行 处 理 的 SQL 语 句 存 
在 ， 基 本 上 意味 着 有 多 个 并 行 查 询 从 属 进程 ( parallel query slave process )， 为 简单 起 见 ， 本 书 全 部 称 
作 从 属 进程 (slave process ) 合作 执行 单独 的 一 条 SQL 语句 。 与 提交 该 SQL 语句 的 会 话 关联 的 服务 进程 
控制 从 属 进 程 之 间 的 协调 。 因 为 这 一 角色 ,经 常 将 该 服务 进程 称 作 查 询 协 调 器 (query coordinator ) 
查询 协调 器 负责 获得 从 属 进 程 ， 为 每 一 个 进程 分 配 一 项 子 任务 ， 收 集 并 组 合 它 们 传递 过 来 的 部 分 结果 
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集 ， 并 将 最 终 的 结果 集 返 回 给 客户 端 。 例 如 ,在 SQL 语句 为 整个 段 执 行 扫 描 的 一 个 例子 中 ， 查 询 协调 
器 能 够 指导 每 个 从 属 进程 去 扫描 该 段 的 一 部 分 并 向 它 传递 必要 的 数据 。 图 15-6 演 示 了 这 个 过 程 。 因 为 
这 四 个 从 属 进程 中 的 每 一 个 都 能 够 在 一 个 不 同 的 CPU 内 核 上 运行 , 在 此 情况 下 响应 时 间 不 再 受到 单一 
CPU 内 核能 够 使 用 的 带宽 的 限制 。 


图 15-6 并行 执行 的 SQL 语句 由 一 个 称 作 查询 协调 器 的 服务 进程 协调 的 多 个 从 属 进 
程 所 处 理 


在 一 次 类 似 图 15-6 所 示 的 并 行 扫描 中 ， 工 作 是 在 从 属 进 程 中 间 按 照 称 作 粒 度 单元 ( granule ) 的 单 
位 进行 分 配 。 每 个 从 属 进程 ， 在 任意 给 定 的 时 间 内 ， 只 处 理 一 个 单独 的 粒度 单元 。 如 果 粒 度 单元 的 数 
量 多 于 从 属 进程 的 数量 ， 当 一 个 从 属 进程 处 理 完毕 一 个 粒度 单元 之 后 ， 它 会 接收 到 男 一 个 要 处 理 的 粒 
度 单元 ， 直 到 所 有 的 粒度 单元 都 被 处 理 完毕 。 数 据 库 引擎 可 以 使 用 以 下 两 种 类 型 的 粒度 单元 。 
口 分 区 粒度 (partition granule ) 是 一 整个 分 区 或 子 分 区 。 显 然 ， 这 种 类 型 的 粒度 单元 只 能 用 于 已 
分 区 段 。 
口 块 范围 粒度 (block range granule ) 是 来 自 一 个 段 在 运行 时 (不 是 在 解析 时 ) 动态 定义 的 一 
系列 块 。 


注意 ”对 于 一 张 外 部 表 的 并 行 扫描 ， 会 将 粒度 单元 定义 为 一 个 外 部 文件 的 一 部 分 (默认 大 小 是 
10 MB )。 所 以 没有 必要 使 用 多 个 外 部 文件 来 允许 并 行 访问 。 


因为 分 区 粒度 的 定义 是 静态 的 ( 只 有 数量 会 因为 分 区 裁剪 而 发 生变 化 )， 大 多 数 时 候 更 倾向 于 使 
用 块 范围 粒度 。 块 范围 粒度 的 主要 优势 是 ， 在 大 多 数 情况 下 ,它们 具备 将 工作 向 从 属 进程 均匀 分 布 的 
条 件 。 事实 上 ,使 用 分 区 粒度 ， 工 作 的 分 布 不 仅 强烈 依赖 分 区 数量 和 从 属 进程 数量 之 间 的 比值 ， 而 且 
还 依赖 每 个 分 区 上 存储 的 数据 总 量 。 假 设 每 个 分 区 包含 近似 相等 的 数据 总 量 。 在 这 种 情况 下， 要 对 工 
作 有 一 个 合理 的 分 配 ， 分 区 的 数量 应 该 是 从 属 进程 数量 的 几 倍 。 如 果 没 有 将 工作 均匀 分 布 ， 某 些 从 属 
进程 可 能 比 其 他 的 多 做 许多 工作 ， 因 此 就 会 导致 更 长 的 响应 时 间 。 结 果 就 是 ， 并 行 执行 的 综合 效率 可 
能 会 受到 损害 。 

下 面 的 执行 计划 展示 了 图 15-6 所 示人 处 理 过 程 的 一 个 例子 : 
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SELECT * FROM 七 


| 0 | SELECT STATEMENT | | | | | 
| 1 | PX COORDINATOR | | | | | 
| 2| PX SEND QC (RANDOM)| :TQO1i0000 | 0Q1,00 | P->S | QC (RAND) | 
| 二】 PX BLOCK ITERATOR | | 0Q1,00 | PCwWC | | 
| 4| TABLE ACCESS FULL| T | 0Q1,00 | PCWP | | 


该 执行 计划 按 以 下 方式 执行 。 

(1) 通过 操作 4 ( TABLE ACCESS FULL )， 每 个 从 属 进程 扫描 表 的 一 部 分 。 从 属 进程 具体 扫描 哪个 部 
分 取决 于 它 的 父 操作 3 ( PX BLOCK ITERATOR )。 这 是 与 块 范围 粒度 有 关 的 操作 。 

(2) 操作 2 (PX SEND Qc ) 将 检索 到 的 数据 发 送 给 查询 协调 需 。 

(3) 查询 协调 器 通过 操作 1 ( PX COORDINATOR ) 从 从 属 进程 接收 数据 并 将 其 发 送 回 客户 端 。 

当 进 程 之 间 发 生 通信 的 时 候 ， 发 送 数据 的 进程 称 作 生 产 者 (producer )， 而 接收 数据 的 进程 则 称 作 
消费 者 ( consumer )。 为 发 送 数据 ， 生 产 者 向 一 个 称 作 表 队 列 的 队列 写 人 数据。 为 接收 数据 ， 消 费 者 
从 表 队 列 读 取 数据 。 根 据 由 生产 者 和 消费 者 执行 的 操作 ， 数 据 使 用 以 下 方法 之 一 进行 分 发 (在 
dbms_xplan 包 的 输出 中 ，PQ Distrib 列 提供 了 此 信息 ); 

口 广播 ( Broadcast ); 每 个 生产 者 向 每 个 消费 者 发 送 所 有 数据 . 

口 本 地 广播 ( Broadcast Local ): 这 是 广播 分 布 的 一 种 变形 。 它 用 于 仅 向 一 部 分 的 从 属 进程 发 送 

所 有 数据 。 它 通常 在 RAC 环 境 中 对 于 最 小 化 跨 实例 通信 比较 有 帮助 。 

口 循环 (Round-robin ): 生产 者 每 次 只 向 一 个 消费 者 发 送 一 行 数据 ， 就 像 发 纸牌 。 因 此 ， 数 据 在 

消费 者 之 间 均 匀 分 布 。 

口 范围 ( Range ): 生产 者 向 不 同 的 消费 者 发 送 特定 范围 的 数据 。 会 执行 动态 范围 分 区 以 确定 应 

该 将 哪 一 行 数据 发 送 给 哪 一 个 消费 者 。 例 如 ， 对 于 一 个 排序 ， 这 个 方法 基于 ORDER BY 子 句 中 使 
用 的 列 对 数据 进行 范围 分 区 ， 所 以 每 个 消费 者 可 以 只 排序 它 自己 那 部 分 数据 ， 

口 散 列 ( Hash ): 生产 者 根据 散 列 函数 向 消费 者 发 送 数据 。 此 过 程 中 会 执行 动态 散 列 分 区 以 确定 
应 该 将 哪 一 行 数据 发 送 给 哪 一 个 消费 者 。 例 如 ， 对 于 一 个 聚合 ， 这 种 方法 可 能 会 根据 GROUP BY 
子 句 中 使 用 的 列 对 数据 进行 散 列 分 区 。 

口 分 区 键 ( Partition Key ): 生产 者 根据 分 区 键 向 消费 者 发 送 数据 。 有关 更 多 信息 , 请 参考 14.7.2 节 

口 混合 散 列 (Hybrid Hash ): 生产 者 或 者 使 用 广播 或 者 使 用 散 列 分 布 方法 向 消费 者 发 送 数据 。 使 
用 这 两 者 中 的 哪 一 个 在 运行 时 决定 。 仅 从 12.1 版 本 开始 可 用 。 

口 单一 从 属 进程 (One Slave ): 生产 者 向 一 个 单独 的 消费 者 发 送 所 有 数据 。 仅 从 12.1 版 本 开始 
可 用 。 

口 查询 协调 器 随机 ( QC Random ): 每 个 生产 者 都 将 所 有 数据 发 送 给 查询 协调 器 。 顺 序 并 不 重要 
( 因此 是 随机 的 )。 这 是 最 常见 的 与 查询 协调 器 通信 所 使 用 的 分 布 方式 。 

口 查询 协调 器 排序 ( QC Order ): 每 个 生产 者 都 将 所 有 数据 发 送 给 查询 协调 器 。 此 时 顺序 很 重要 。 

例如 ， 并 行 执行 的 排序 会 使 用 这 种 方法 将 数据 发 送 给 查询 协调 器 。 
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并 行 操作 之 间 的 关系 
在 并 行 执行 的 执行 计划 中 会 用 到 的 并 行 操作 之 间 的 关系 如 下 所 示 
口 并 行 至 囊 行 (P->S ); 一 个 并 行 操作 向 一 个 串 行 操作 发 送 数 据 。 例如， 这 个 操作 用 于 在 执行 
计划 中 向 查询 协调 器 发 送 数 据 
口 并 行 至 并 行 (P->P ): 一 个 并 行 操作 向 另 一 个 并 行 操作 发 送 数 据 。 有 两 组 从 属 进程 存在 的 时 
候 会 用 到 这 个 操作 
口 与 父 操 作 组 合 的 并 行 操作 (PCWP ): 一 个 被 并 行 执行 的 操作 ， 相 同 的 从 属 进程 还 会 执行 该 执 
行 计 划 中 的 父 操作 。 因 此 ， 不 会 有 通信 发 生 
口 与 子 操作 组 合 的 并 行 操作 (PCWC ): 一 个 被 并 行 执 行 的 操作 ， 相 同 的 从 属 进程 还 会 执行 该 执 
行 计划 中 的 子 操作 。 因 此 ， 不 会 有 通信 发 生 
口 串 行 至 并 行 (S->P ): 一 个 串 行 执行 的 操作 向 一 个 并 行 执行 的 操作 发 送 数 据 。 因 为 大 多 数 时 
候 这 是 没有 效率 的 ， 它 应 该 被 避免 。 没 有 效率 的 一 个 主要 的 原因 : 一 个 单独 的 进程 能 够 产生 
数据 的 速度 ， 可 能 无 法 跟 上 多 个 进程 能 够 消耗 的 速度 。 如 果 就 是 这 种 情况 ,消费 者 就 会 花费 
大 量 的 时 间 等 待 数据 而 不 是 做 真正 的 在 工作 
口 与 父 操作 组 合 的 串 行 操作 (SCWP ): 一 个 被 串 行 执行 的 操作 ， 相 同 的 从 属 进程 还 会 执行 该 执 
行 计划 中 的 父 操作 。 因 此 ， 不 会 有 通信 发 生 。 从 12.1 版 本 开始 可 用 
口 与 子 操作 组 合 的 串 行 操作 ( SCWC ): 一 个 被 串 行 执行 的 操作 ， 相 同 的 从 属 进程 还 会 执行 该 
执行 计划 中 的 子 操作 。 因 此 ， 不 会 有 通信 发 生 。 从 12.1 版 本 开始 可 用 。 
在 由 dbms_xplan 包 生成 的 输出 中 ， 并 行 操作 之 间 的 关系 在 IN-0UT 列 中 提供 
TP ss 
以 一 个 序列 形式 执行 的 多 个 并 行 操作 集体 称 为 数据 流 操 作 ( data flow operation，DFO ), 在 很 多 情 
况 下 ， 执 行 计 划 拥 有 一 个 单独 的 数据 流 操作 。 但 是 ,也 存在 需要 多 个 数据 流 操作 的 情况 。 要 想 知道 数 
据 流 操作 的 数量 ， 必 须 检 查 由 dbms_xplan 包 生成 的 输出 中 的 To 列 。 通 过 它 ， 不 仅 可 以 确定 在 一 个 执行 
计划 中 使 用 了 多 少 个 数据 流 操 作 ， 而 且 还 可 以 知道 哪些 操作 是 由 哪 一 组 从 属 进程 执行 的 。 事 实 上 ，TO 
列 的 内 容 提供 以 下 信息 。 
口 值 为 NULL 与 查询 协调 器 执行 的 操作 对 应 ， 
口 前 级 为 字母 Q 的 值 与 数据 流 操 作 的 ID 对 应 。 
口 跟 在 逗号 后 面 的 值 与 一 组 从 属 进 程 写 人 数据 的 表 队 列 的 人 D 对 应 。 你 无 法 知晓 有 和 多少 个 从 属 进 
程 属 于 这 一 组 。 
在 前 面 的 执行 计划 中 , 因为 值 01,00 的 缘故 , 你 知道 操作 2 到 操作 4 属于 一 个 单独 的 数据 流 操 作 ( ID 
是 1 的 那些 )， 而 且 它 们 都 只 是 被 单独 一 组 从 属 进程 执行 的 (ID 是 0 的 那些 ). 
数据 访问 操作 并 非 唯 一 可 以 并 行 执行 的 操作 。 事 实 上 ， 数 据 库 引 擎 也 能 够 并 行 化 插入 、 联 接 、 取 
合 和 排序 等 操作 。 当 一 条 SQL 语 句 执行 两 个 或 更 多 的 独立 操作 ( 例如 ， 扫 描 和 排序 ) 时 ， 数 据 库 引擎 
通常 会 使 用 两 组 从 属 进程 。 举 例 来 说 ， 如 图 15-7 所 示 ， 如 果 一 条 SQL 语 句 执 行 一 次 扫描 ， 然 后 是 一 次 [as 
排序 ， 则 一 组 用 于 扫描 而 另外 一 组 用 于 排序 
一 个 独立 操作 的 并 行 化 称 为 内 部 操作 并 行 ( intra-operation parallelism )。 举 例 来 说 ， 在 图 15-7 中 ， 
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内 部 操作 并 行 (使 用 四 个 从 属 进程 ) 被 使 用 了 两 次 : 一 次 用 于 扫描 ,一 次 用 于 排序 。 当 两 组 从 属 进 程 


被 用 于 执行 一 个 数据 流 操 作 ， 该 并 行 化 称 为 交互 操作 并 行 化 ( inter-operation parallelism )。 举 例 来 说 ， 
在 图 15-7 中 ， 交 互 操作 并 行 化 被 用 于 第 一 组 进程 (扫描 ) 和 第 二 组 进程 (排序 ) 之 间 。 


结果 集 


图 15-7 ”两 组 从 属 进程 可 以 用 于 执行 同一 条 SQL 请 句 


下 面 的 执行 计划 是 图 15-7 所 示人 处 理 过 程 的 一 个 例子 : 
SELECT * FROM t ORDER BY id 


| Id | Operation | Name To |IN-OUT| PQ Distrib | 
| 0 | SELECT STATEMENT | 
| 1 | PX COORDINATOR | 
| 2| PX SEND QC (ORDER) :TQ10001 | Q1,01 | P->S | QC (ORDER) | 
“党 阐 SORT ORDER BY 01,01 | PCWP | 
| 声 j PX RECEIVE Q1,01 | PCWP | 
| PX SEND RANGE :TO10000 | 01,00 | P->P | RANGE | 
| 6| PX BLOCK ITERATOR 0Q1,00 | PCWC | 
| 笃 中 TABLE ACCESS FULL| T Q1,00 | PCWP | 


上 面 的 执行 计划 是 由 一 个 单独 的 数据 流 操 作 组 成 (ID 为 1 那些 ),。 操作 5 到 7 在 列 TQO 上 拥有 相同 的 值 
( 01,00 )， 也 就 是 说 它们 是 被 同一 组 从 属 进程 执行 的 ( 图 15-7 中 的 第 一 组 )。 另 一 方面 ， 操 作 2 到 操作 4 
拥有 男 一 个 值 (01,01 ), 因此 它们 是 被 另 一 组 从 属 进程 执行 的 (图 15-7 中 的 第 二 组 ) 第 一 组 是 生产 者 ， 
基于 块 范围 粒度 扫描 表 ( 操作 6 ) 并 将 检索 到 的 数据 发 送 给 第 二 组 。 接 下 来 ， 第 二 组 作为 消费 者 ， 接 
收 数据 ， 对 其 排序 ， 然 后 将 排序 的 结果 集 发 送 给 查询 协调 器 。 第 一 组 和 第 二 组 同步 进行 它们 的 处 理 过 
程 。 因 为 这 两 组 从 属 进程 相互 通信 ， 处 理 数据 较 快 的 那 一 组 会 等 等 男 外 一 组 。 


2. 基本 配置 
本 部 分 主要 描述 要 成 功 设置 一 个 用 于 并 行 处 理 的 数据 库 实例 ， 你 必须 要 了 解 的 基本 初始 化 参数 。 
这 些 初 始 化 参数 涉及 从 属 进程 池 和 内 存 利用 。 
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@ 从 属 进 程 池 
每 个 数据 库 实例 的 最 大 从 属 进程 数量 是 有 限 的 , 并 且 由 一 个 数据 库 实 例 以 从 属 进程 池 的 方式 进行 
维护 。 查 询 夫 调 器 从 池 中 请 求 从 属 进程 ， 使 用 它们 来 执行 一 条 SQL 语 句 ， 最 终 ， 当 执行 完成 时 ， 将 它 
们 返还 给 这 个 池 。 可 以 通过 设置 下 面 的 初始 化 参数 来 配置 这 个 池 。 
口 parallel_min_servers 指 定 在 数据 库 实例 启动 时 启动 的 从 属 进程 数量 。 这 些 从 属 进程 总 是 处 于 
可 用 状态 ， 而 且 当 一 个 服务 进程 请 求 它们 的 时 候 不 需要 启动 。 当 请 求 超过 这 个 最 小 数量 时 ， 
会 以 动态 方式 启动 从 属 进程 ， 而 且 一 旦 返还 给 进程 池 ， 会 保持 空闲 状态 5 分 钟 。 如 果 在 这 一 时 
间 段 内 没有 被 重用 ， 就 会 关闭 它们 。 默 认 情况 下 ， 会 将 这 个 初始 化 参数 设置 为 0"。 这 意味 着 
在 最 初 的 时 候 不 会 启动 任何 从 属 进程 。 我 建议 只 在 当 一 些 SQL 语 句 花 费 过 长 的 时 间 等 待 从 属 进 
程 的 启动 时 才 去 更 改 这 个 值 。 与 这 个 操作 关联 的 等 待 事件 是 os thread startup。 
口 parallel max_servers 指 定 池 中 可 用 从 属 进程 的 最 大 数量 。 很 难 给 出 关于 如 何 设置 这 个 参数 的 
建议 。 虽 然 如 此 ，CPU 内 核 数 量 的 10~20 倍 是 一 个 不 错 的 开始 。 默 认 值 还 依赖 于 其 他 几 个 初始 
化 参数 、 版 本 以 及 平台 。 可 以 将 parallel max_servers 的 最 大 值 设置 为 比 processes 初 始 化 参数 
的 值 小 15 的 数值 。 如 果 尝 试 将 parallel max_servers 设 置 为 一 个 更 高 的 值 ， 那 么 在 数据 库 实 例 
启动 的 时 候 ， 会 自动 调整 parallel_max_servers， 并 且 会 在 alert 日 志 中 写 和 一 条 消息 。 
要 显示 池 的 状态 ， 可 以 使 用 下 面 的 查询 : 


SQL> SELECT * 
2 FROM v$px_process sysstat 
3 WHERE statistic LIKE 'Servers%'; 


STATISTIC VALUE 
Servers In Use 

Servers Available 8 
Servers Started 46 
Servers Shutdown 34 
Servers Highwater 12 
Servers Cleaned Up 0 


在 RAC 环 境 中 , 每 个 数据 库 实例 都 是 群集 的 一 部 分 ， 且 拥有 它们 自己 的 从 属 进程 池 。 当 以 并 行 方 

式 执 行 一 条 SQL 语句 时 ， 从 属 进程 既 可 以 从 本 地 分 配 ， 也 可 以 从 一 个 单独 的 实例 远程 分 配 ， 或 从 多 个 
数据 库 实例 分 配 。 下 面 的 方法 可 以 用 于 控制 从 哪些 数据 库 实例 分 配 从 属 进程 。 

口 parallel instance_group 和 instance_groups 初 始 化 参数 可 以 用 于 将 从 属 进 程 的 分 配 限制 到 指 

定 的 数据 库 实 例 上 。 通 过 ;instance_groups 初 始 化 参数 ， 你 指定 每 个 数据 库 实 例 所 处 的 实例 组 。 

通过 parallel_instance_group 初 始 化 参数 ， 你 指定 从 属 进 程 从 哪个 实例 组 分 配 。 从 11.1 版 本 开 

始 ， 不 再 赞成 使 用 instance_groups 初 始 化 参数 。 所 以 刚刚 描述 的 这 种 方法 仅 适 用 于 10.2 版 本 。 

口 从 11.1 版 本 开始 ,从 属 进程 的 分 配 是 服务 感知 的 。 从 属 进 程 仅 从 特定 实例 中 分 配 ， 这 些 实例 与 

通过 并 行 方 式 执行 SQL 语句 的 会 话 所 在 实例 处 于 相同 的 服务 之 下 。 从 11.1 版 本 开始 ,这 种 方法 


取代 了 前 一 种 。 
口 从 11.2 版 本 开始 ,将 parallel force local 初始 化 参数 设置 为 TRUE ( 默认 值 是 FALSE ) 时 只 会 分 
配 本 地 的 从 属 进程 。 


站 自 12.1 版 本 起 ，parallel min_servers 初 始 化 参数 为 "cpu_count*parallel threads_per_cpu*2"， 而 不 是 此 处 的 0。 
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因为 从 属 进程 池 的 配置 是 具体 到 数据 库 实例 的 ， 在 12.1 多 租户 环境 下 ， 不 能 在 PDB 级 别 设置 
parallel min servers 和 parallel max servers 初 始 化 参数 。 但 是 ,可 以 通过 数据 库 服 务 或 
parallel force local 初始 化 参数 在 PDB 级 别 控制 从 属 进程 的 分 配 。 


@ 内 存 利用 
用 于 在 进程 之 间 通 信 的 表 队 列 是 可 以 从 shared pool 或 large pool 中 分 配 的 内 存 结构 。 然 而 ， 不 推荐 
为 它们 使 用 shared pool。Large pool 专 用 于 不 可 重用 的 内 存 结构 ， 是 一 个 更 好 的 选择 。 以 下 两 个 配置 可 
以 引导 表 队 列 使 用 large pool。 
口 自动 SGA 管 理 是 通过 sga_target 或 memory_target 启 用 的 (后 者 仅 从 11.1 版 本 开始 可 用 ) 
口 将 parallel automatic tuning 初 始 化 参数 设置 为 TRUE。 注意. 这 个 初始 化 参数 是 不 再 赞成 使 用 
的 。 然 而 ， 如 果 不 想 使 用 自动 SGA 管 理 ， 设 置 它 是 引导 并 行 处 理 使 用 large pool 的 唯一 途径 。 


注意 不 去 管 它 的 名 称 ，parallel automatic tuning 初 始 化 参数 只 做 两 件 简单 的 事情 。 第 一 ， 它 改变 
几 个 与 并 行 处 理 有 关 的 初始 化 参数 的 默认 值 , 第 二 , 它 通知 数据 库 引 擎 为 表 队 列 使 用 large pool 


每 个 表 队 列 是 由 三 个 缓冲 区 (使 用 RAC 时 最 多 五 个 ) 组 成 ,这些 缓冲 区 是 与 通过 表 队 列 通信 的 每 
一 对 进程 相对 应 的 。 每 个 缓存 的 大 小 ( 按 字 节 计 ) 是 通过 parallel execution _message size 初 始 化 参 
数 设置 的 。 其 默认 值 取决 于 数据 库 引 擎 版 本 。 直 到 11.1 版 本 ， 它 要 么 是 2152 个 字 节 ， 要 么 是 将 
parallel automatic tuning 初 始 化 参数 设置 为 TRUE 时 的 4096 个 字 节 。 从 11.2 版 本 开始 ,默认 大 小 是 16KB。 
出 于 最 佳 性 能 考虑 ， 应 该 将 它 设置 为 能 够 支持 的 最 大 值 。 取 决 于 所 使 用 的 平台 , 可 以 是 16 KB、32 KB 
或 64 KB。 因 此 ， 尤 其 是 在 11.2 版 本 之 前 ,我 建议 你 修改 其 默认 值 。 

当 增 大 parallel execution_message_size 初 始 化 参数 的 值 时 ， 应 该 确保 有 足够 的 内 存 可 用 。 可 以 
使 用 公式 15-1 来 估算 对 于 非 RAC 数 据 库 实例 large pool 中 应 该 保持 可 用 的 最 大 内 存 总 量 , 出 于 这 个 目的 ， 
这 个 公式 计算 在 需要 两 组 从 属 进程 并 且 使 用 可 能 的 最 大 并 行 度 ( parallel max_servers 初 始 化 参数 的 
一 半 ) 执行 时 ， 必 要 的 缓存 数量 是 多 少 。 注 意 ， 在 RAC 环 境 中 , 不 仅 每 一 对 进程 之 间 通 信 的 缓存 数量 
可 以 更 高 一 些 ( 最 高 到 5 而 非 3 )， 而 且 最 大 并 行 度 也 取决 于 实例 的 数量 。 

公式 15-1 表 队 列 的 非 RAC 数 据 库 实例 使 用 的 large pool 内 存 总 量 


parallel_ max servers” 


4 | parallel_execution_message_ size 


large_ pool_size>3 | parallel_max_ servers+ 
要 显示 数据 库 实例 目前 正在 使 用 的 large pool 内 存 有 和 多少， 可 以 运行 下 面 的 查询 : 


SQL> SELECT * 
2 FROM v$sgastat 
3 WHERE name = 'PX msg pool'; 


POOL NAME BYTES 


large pool PX msg pool 823296000 
可 以 运行 下 面 的 查询 来 显示 当前 分 配 的 表 队 列 缓存 数量 ( Buffers Current 统 计 信 息 )， 以 及 月 数 
据 库 实例 启动 以 来 一 次 分 配 过 的 最 大 数量 ( Buffers HWM 统 计 信 息 ): 
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SQL SELECT = 
2 FROM v$px process sysstat 
3 WHERE statistic IN ('Buffers Current 


4 'Buffers HWM 中 有 
STATISTIC VALUE 
Buffers Current 45076 
Buffers HWM 49924 


因为 内 存 配置 是 具体 到 数据 库 实例 的 ， 所 以 在 12.1 多 租户 环境 下 ， 不 可 能 在 PDB 级 别 设置 
parallel automatic tuning 和 parallel execution message size 初始 化 参数 。 

在 RAC 环 境 中 每 个 数据 库 实例 可 以 拥有 它 自己 的 内 存 设置 。 唯 一 的 例外 是 parallel execution_ 
message_size 初 始 化 参数 。 事 实 上 ， 如 果 将 这 个 参数 设置 为 不 同 的 值 ， 则 数据 库 实 例 之 间 无 法 互相 通 
信 。 这 种 情况 下 ， 执 行 一 条 涉及 多 个 数据 库 实 例 的 SQL 语句 时 ， 就 会 引发 一 个 错误 。 下 面 是 此 类 错误 
的 一 个 例子 : 

SOL> SELECT * FROM gv$instance; 

Ee * FROM gv$instance 


ERROR at line 1: 

ORA-12850: Could not allocate slaves on all specified instances: 2 needed, 1 allocated 

ORA-12801: error signaled in parallel query server P001, instance 32766 

3. 并 行 度 

用 于 内 部 操作 并 行 化 的 从 属 进程 数量 称 作 并 行 度 ( DOP )。 因 为 并 行 度 规定 用 于 内 部 操作 并 行 化 
的 从 属 进程 数量 ， 所 以 在 使 用 交互 操作 并 行 化 时 ， 用 于 执行 一 条 SQL 语 句 的 从 属 进程 数量 要 比 并 行 度 
高 一 些 。 无 论 如 何 , 一 个 单独 的 数据 流 操作 无 法 使 用 高 于 并 行 度 两 倍数 量 的 从 属 进程 。 举 例 来 说 ,图 
15-7 展 示 了 一 个 从 属 进程 的 数量 是 并 行 度 两 倍 的 例子 . 

当 并 行 处 理 一 条 SQL 语 句 ( 或 者 其 中 一 部 分 ) 的 时 候 ， 数 据 库 引擎 不 得 不 选择 用 于 此 目的 的 并 行 
度 。 尽 管 有 几 个 初始 化 参数 和 其 他 的 因素 决定 实际 的 并 行 度 , 但 实际 上 只 有 两 种 主要 的 模式 可 以 用 于 
设置 一 个 数据 库 实 例 以 控制 并 行 度 。 

口 手动 并 行 度 : 在 这 种 模式 下 ， 可 以 在 会 话 、 对 象 或 SQL 语句 中 的 任意 一 个 级 别 控制 并 行 度 。 

口 自动 并 行 度 : 在 这 种 模式 下 ， 数 据 库 引擎 自动 为 每 条 SQL 语句 选择 最 优 的 并 行 度 。 

手动 并 行 度 控制 是 11.1 及 之 前 版 本 中 唯一 可 用 的 模式 。 


警告 ”建议 仅 从 11.2.0.3 版 本 开始 使 用 自动 并 行 度 。 原因 是 在 此 之 前 的 版 本 中 ， 有 几 个 bug 使 得 自动 控 
制 很 难 实现 。 请 参考 Oracle Support 文 档 Init.ora Parameter “PARALLEL DEGREE _POLICY” 
Reference Note ( 1216277.1 ) 获取 更 多 信息 。 还 要 注意 ， 在 11.2.0.2 版 本 中 ， 自 动 并 行 度 的 功能 
性 方面 引入 了 一 些 变化 。 我 不 觉得 在 11.2.0.3 之 前 的 版 本 中 使 用 它 有 多 大 意义 ， 所 以 11.2.0.1 版 
本 的 功能 在 本 书 中 不 做 介绍 


从 11.2 版 本 开始 ，parallel degree_policy 初 始 化 参数 不 仅 用 于 在 手动 和 自动 并 行 度 之 间 进 行 先 
择 ， 而 且 还 会 启用 其 他 与 并 行 处 理 相关 的 特性 。 它 接受 以 下 值 。 
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口 manual: 启用 手动 并 行 度 。 这 是 默认 值 。 

口 limited: 只 为 引用 了 将 PARALLEL 设置 为 DEFAULT ( 详细 信息 见 下 ) 的 对 象 的 SQL 语句 局 用 自动 
并 行 度 。 对 于 其 他 语句 ， 使 用 手动 并 行 度 。 

口 auto: 为 所 有 SQL 诸 句 启用 自动 并 行 度 。 此 外 , 还 启用 了 其 他 两 个 特性 : 并 行 语句 排队 ( parallel 
statement queuing ) 和 内 存 中 并 行 执 行 (in-memory parallel execution ) 

口 adaptive: 这 种 模式 类 似 于 auto。 唯一 的 区 别 是 同时 还 启用 了 性 能 反馈 ( performance feedback ) 
这 个 值 仅 从 12.1 版 本 开始 可 用 。 


注意 ”并行 语 名 排队、 内 存 中 并 行 执行 ， 以 及 性 能 反馈 都 与 自动 并 行 度 无 关 。 因 此 令 人 遗憾 的 是 ， 
它们 都 是 被 同一 个 单独 的 初始 化 参数 激活 的 。 如 果 可 以 有 选择 性 地 激活 它们 就 好 多 了 


parallel degree_policy 初 始 化 参数 可 以 在 会 话 级 别 进行 设置 , 从 12.1 版 本 开始 可 以 在 PDB 级 别 进 
行 设 置 。 也 可 以 在 SQL 语句 级 别 通 过 使 用 语句 级 别 的 语法 指定 parallel hint 来 覆盖 它 的 值 。parallel 
hint 支 持 以 下 值 。 

口 parallel(manual) 激活 手动 并 行 度 。 

口 parallel(auto) 激活 自动 并 行 度 (但 是 不 会 激活 并 行 语句 排队 和 内 存 中 并 行 执行 ). 

口 parallel(n) 将 并 行 度 设置 为 作为 参数 (n) 指 定 的 整数 值 。 


警告 ”从 11.2 版 本 开始 ，parallel hint 支 持 两 种 语法 : 语句 级 别 和 对 象 级 别 。 语句 级别 的 语法 ， 就 像 
刚才 描述 的 ， 在 SQL 语句 级 别 履 盖 parallel degree_policy 初 始 化 参数 。 对 象 级 别 的 语法 ， 在 
接 下 来 的 “手动 并 行 度 ” 一 节 中 讲述 ， 会 徐 盖 与 表 以 及 索引 相关 的 并 行 度 。 


下 面 儿 个 部 分 的 主要 目标 , 是 描述 在 不 考虑 从 属 进程 数量 可 能 会 被 系统 的 负载 或 其 他 因素 限制 的 
情况 下 ,数据 库 引 擎 如 何 决 定 并 行 度 。 稍 后 ,“ 限 制 并 行 度 ”部 分 会 描述 并 行 度 可 能 会 被 减少 的 情况 。 

@ 默认 并 行 度 

通常 所 谓 的 默认 并 行 度 , 实际 上 可 能 是 你 想 为 任何 一 个 并 行 SQL 语句 使 用 的 最 大 并 行 度 。 事实 上 ， 
只 有 在 任意 给 定时 间 点 最 多 有 运行 一 条 SQL 语句 时 默认 值 才 运行 良 好 。 如 何 使 用 以 及 何 时 使 用 默认 值 
取决 于 多 个 因素 ， 比 如 数据 库 实 例 配置 。 接 下 来 的 两 个 小 节 , 在 讨论 手动 和 自动 并 行 度 是 如 何 工作 的 
时 候 ， 会 提供 更 多 关于 默认 并 行 度 的 信息 。 

为 计算 默认 并 行 度 ,如 公式 15-2 所 示 ,， 数据 库 引 警 将 cpu_count 初 始 化 参数 的 值 乘 以 一 个 CPU 内 核 
预期 可 以 处 理 的 从 属 进程 数量 ( parallel threads_per cpu 初始化 参数 )， 延 伸 到 RAC 环 境 中 时 ， 结 果 
值 要 进一步 乘 以 群集 中 数据 库 实例 的 数量 。 

公式 15-2 默认 并 行 度 是 你 可 能 想 为 任何 一 条 并 行 SQL 语 句 使 用 的 最 大 并 行 度 


default_dop = cpu_count: parallel_threads per_cpu* number_ of instances 


提示 在 大 多 数 平台 上 , parallel threads_per_cpu 初 始 化 参数 的 默认 值 是 2, 假如 在 CPU 级 别 启 用 了 
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多 线程 ， 结 果 就 是 ，cpu count 初始 化 套数 的 值 被 人 为 地 提高 了 ， 我 建议 此 时 将 
parallel threads_per cpu 初始 化 套数 设置 为 1。 


@ 手动 并 行 度 

每 张 表 和 每 个 索引 都 有 一 个 关联 的 并 行 度 。 对 于 引用 该 对 象 的 操作 默认 会 使 用 这 个 并 行 度 。 它 的 
默认 值 是 1， 也 就 是 说 不 使 用 并 行 处 理 。 如 下 面 SQL 语句 所 示 ， 并 行 度 通过 使 用 pARALLEL 子 句 设置 ， 既 
可 以 在 创建 对 象 时 使 用 ， 也 可 以 在 稍 后 使 用 : 

CREATE TABLE t (id NUMBER，pad VARCHAR2(1000) ) PARALLEL 4 

ALTER TABLE 七 PARALLEL 2 

CREATE INDEX i ON t (id) PARALLEL 4 


ALTER INDEX i PARALLEL 2 


警告 使 用 并 行 处 理 来 改进 维护 任务 或 创建 表 和 索引 的 批 处 理 任务 等 操作 性 能 的 做 法 十 分 常见 。 出 
于 这 个 目的 ， 通 常会 指定 PARALLEL 子 句 。 但 是 要 知道 , 使 用 这 个 子 句 时， 该 并 行 度 不 仅 用 于 表 
或 索引 的 创建 期 间 ， 而 且 日 后 引用 这 些 表 或 索引 的 操作 中 也 会 使 用 该 并 行 度 。 因 此 ， 如 果 只 
想 在 表 或 索引 的 创建 期 间 使 用 并 行 处 理 ， 一 定 要 记得 在 创建 完毕 后 修改 并 行 度 。 


要 禁用 并 行 处 理 ， 要 么 将 并 行 度 设置 为 !， 要 人 么 指定 NOPARALLEL 子 句 : 
ALTER TABLE t PARALLEL 1 


ALTER INDEX i NOPARALLEL 


在 没有 指定 并 行 度 的 情况 下 使 用 PARALLEL 子 句 时 ( 例如 ，ALTER TABLE t PARALLEL )， 应 使 用 默认 
并 行 度 。 因 为 默认 值 只 是 在 你 想 在 任意 给 定时 间 内 执行 至 多 一 条 SQL 语句 时 有 好 处 ， 我 通常 推荐 还 是 
指定 一 个 值 。 

要 覆盖 在 表 或 索引 级 别 上 定义 的 并 行 度 ， 可 以 使 用 parallel 、no_parallel 、parallel index 以 及 
no_parallel index 这 几 个 hint。 事 实 上 ， 当 这 些 hint 和 对 象 级 别 语 法 一 起 使 用 时 ， 前 两 个 覆盖 表 级 别 的 
设置 ， 第 三 个 和 第 四 个 覆盖 索引 级 别 的 设置 。 我 强调 一 下 对 象 级 别 的 语法 ,指定 对 象 名 称 或 别名 的 那 
个 语法 ， 必 须 使 用 。 下 面 是 使 用 这 个 语法 时 不 仅 指 定 对 象 名称 (t 是 指 表 ， i 是 索引 ) 而 且 还 有 并 行 度 
( 16 ) 的 例子 : 

SELECT /*+ parallel(t 16) */ * FROM t 

SELECT /*+ parallel index(t i 16) */ * FROM 七 

通过 parallel 这 个 hint， 还 可 以 显 式 要 求 使 用 默认 并 行 度 : 

SELECT /*+ parallel(t default) */ * FROM t 

在 一 个 单独 的 数据 流 操 作 中 为 不 同 的 表 或 索引 指定 不 同 的 并 行 度 时 , 数据库 引 警 会 为 整个 数据 流 
操作 计算 一 个 单独 的 并 行 度 。 一 般 而 言 ， 所 选择 的 并 行 度 就 是 在 表 或 索引 级 别 指定 的 最 大 的 那个 。 
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@ 自动 并 行 度 

使 用 自动 并 行 度 的 想法 非常 简单 : 对 于 每 一 条 SQL 语句 , 由 查询 优化 器 选择 最 优 的 并 行 度 。 因此， 
查询 优化 器 根据 执行 计划 和 预期 需要 完成 的 处 理 总 量 调整 并 行 度 。 作 为 一 个 例子 ， 图 15-8 展 示 了 当 我 
在 不 同 大 小 的 表 上 执行 全 表 扫 描 的 时 候 ， 查 询 优化 器 在 我 的 测试 服务 器 上 选择 的 并 行 度 。 注 意 为 执行 
这 个 测试 ， 我 执行 了 px_dop_auto.sql 脚 本 。 


_ | 
12 
攻 7 
丰 8 有 
| 
0 
0.1 10 20 30 40 


表 的 大 小 (GB) 


图 15-8 在 最 小 值 (1) 和 最 大 值 ( 16 ) 之 间 ， 并 行 度 随 着 处 理 总 量 
(发 生 全 表 扫 描 的 段 大 小 ) 成 比例 增加 


图 15-8 显 示 ， 一 方面 ， 在 一 个 阀 值 之 下 查询 优化 咒 会 决定 以 串 行 方式 运行 一 条 SQL 语 句 ， 而 另 一 
方面 ， 也 存在 一 个 不 会 被 逾越 的 最 大 并 行 度 。 

该 国 值 的 定义 是 ， 在 考虑 并 行 处 理 之 前 ， 一 条 SQL 语句 以 串 行 方式 执行 应 该 持续 的 最 小 时 间 总 量 
(根据 查询 优化 器 的 估算 )。 它 是 通过 parallel min _ time threshold 初 始 化 参数 配置 的 。 默 认 值 是 自动 
的 ， 当 前 是 等 于 10 秒 钟 。 如 果 想 要 更 改 那个 国 值 ， 可 以 设置 parallel_min_time_threshold 初 始 化 参数 
来 满足 你 预期 的 秒 数 。 

最 大 并 行 度 取决 于 parallel degree limit 初始 化 参数 。 可 以 将 它 设 置 为 以 下 值 之 一 。 

口 CPU: 最 大 并 行 度 等 于 默认 并 行 度 。 此 为 默认 值 。 

口 I0: 最 大 并 行 度 由 磁盘 IO 上 限定 义 。 参 考 本 章 稍 后 的 “磁盘 IO 上 限 ” 部 分 以 获取 关于 它 的 额 

外 信息 。 

口 一 个 整数 值 显 式 指定 最 大 并 行 度 。 

要 使 用 自动 并 行 度 ， 必须 满足 两 个 条 件 。 首先 , 通过 IO 口径 收集 的 统计 信息 必须 可 用 。 这 些 统计 
言 息 都 是 什么 以 及 如 何 收集 它们 会 在 下 一 部 分 “磁盘 IO 上 限 ” 中 介绍 。 其 次 ， 该 特性 必须 通过 
parallel degree_policy 初 始 化 参数 或 parallel(auto) hint 来 启用 。 将 parallel_degree_policy 初 始 化 参 
数 设置 为 limited 时 ,有 一 个 额外 的 要 求 : 只 会 对 那些 拥有 相关 的 默认 并 行 度 的 表 和 索引 考虑 使 用 并 行 
处 理 。 下 面 的 例子 ， 来自 px_dop_limited.sql 脚 本 的 输出 ， 证 实 了 这 一 点 : 

SQL> ALTER SESSION SET parallel degree policy = limited; 
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SOL> ALTER TABLE t NOPARALLEL; 


SQLS SELECT * FROM 3 


| Id | Operation | Name | 


| 0 | SELECT STATEMENT | | 
| 1 | TABLE ACCESS FULL| T 


SOL> ALTER TABLE 七 PARALLEL; 


SQL> SELECT * FROM 七 ; 


| Id | 0peration | Name | TO |IN-OUT| PQ Distrib | 


| 0 | SELECT STATEMENT | | 
| 1 | PX COORDINATOR | | 
| 2| PX SEND QC (RANDOM)| :TQ10000 | 
| 3| PX BLOCK ITERATOR | 

| 4| TABLE ACCESS FULL| T | 


- automatic DOP: Computed Degree of Parallelism is 4 because of degree limit 


上 面 例子 中 由 dbms_xplan 包 生成 的 Note 部 分 最 后 一 行 输出 清晰 地 表明 是 否 使 用 了 自动 并 行 度 ,而 
且 ， 如 果 使 用 了 ， 还 会 提 到 选择 的 并 行 度 大 小 。 其 他 可 以 出 现在 Note 部 分 与 自动 并 行 度 相关 的 消息 
如 下 : 


automatic DOP: Computed Degree of Parallelism is 2 
automatic DOP: Computed Degree of Parallelism is 1 because of parallel threshold 


automatic DOP: skipped because of IO calibrate statistics are missing 

如 果 由 查询 优化 器 选择 的 并 行 度 不 合理 ， 从 12.1 版 本 开始 ， 可 以 通过 parallel degree level 初 始 
化 参数 调整 其 估算 。 它 的 默认 值 是 100。 如 果 你 指定 的 值 低 于 100， 并 行 度 会 按 比 例 减 小 。 举 例 来 说 ， 
使 用 值 50 时 , 并 行 度 减 少 30%, 如 果 你 指定 的 值 高 于 100, 并 行 度 会 按 比例 增加 。 举例 来 说 , 使 用 值 200 
时 ， 假 如 没有 超过 最 大 值 ， 则 并 行 度 翻 倍 。 


4. 限制 并 行 度 

上 一 部 分 中 描述 了 数据 库 引 擎 如 何 决定 并 行 度 ; 本 部 分 描述 那些 由 数据 库 引擎 确定 的 并 行 度 可 能 
被 减少 的 情况 。 具 体 来 说 ， 并 行 度 减少 会 在 以 下 情况 下 发 生 : 

口 启用 自 适 应 并 行 度 时 

口 启用 磁盘 WO 上 限时 

口 数据 库 资源 管理 器 ( Database Resource Manager ) 限制 了 并 行 度 时 
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口 用 户 配 置 文件 限制 了 一 个 具体 的 用 户 可 以 拥有 的 并 行 会 话 数 时 
注意 ， 也 可 以 同时 启用 这 些 特性 中 的 多 个 。 


警告 只 有 在 满足 两 个 条 件 的 时 候 ， 查 询 优化 器 才 会 知晓 本 部 分 描述 的 技术 所 施加 的 限制 : 限制 是 
通过 数据 库 资 源 管理 器 施加 的 ， 并 且 使 用 自动 并 行 度 。 在 其 他 所 有 情况 下 ， 查 询 优化 器 并 不 
知晓 有 一 个 限制 被 施加 到 并 行 度 上 的 事实 。 注 意 知晓 这 个 信息 非常 关键 ， 因 为 由 查询 优化 器 
估算 的 成 本 确实 依赖 并 行 度 。 因 此 ， 当 不 知道 限制 的 存在 时 ， 查 询 优化 器 可 能 选择 一 个 不 良 
的 执行 计划 。 


@ 自 适应 并 行 度 
自 适 应 并 行 度 是 由 parallel adaptive_multi_user 初 始 化 参数 控制 的 。 它 的 用 途 是 影响 分 配给 一 个 
服务 进程 的 从 属 进程 数量 。 它 接受 以 下 两 个 值 。 
口 FALSE: 如 果 进 程 池 没有 被 耗 尽 ， 则 从 属 进程 会 被 按 请 求 的 数量 分 配给 服务 进程 。 
口 TRUE: 随 着 已 经 分 配 的 从 属 进程 数量 的 增加 ,请求 的 并 行 度 会 被 自动 减 小 , 即使 池 中 可 能 仍 有 
足够 的 从 属 进程 满足 请 求 的 并 行 度 。 此 为 默认 值 。 


注意 ”parallel _ adaptive _ multi user 初 始 化 参数 只 在 两 种 情况 下 起 作用 : 第 一 ， 当 使 用 手动 并 行 度 
的 时 候 ; 第 二 , 将 parallel degree policy 初 始 化 参数 设置 为 limited 的 情况 下 使 用 自动 并 行 度 
的 时 候 。 


为 了 演示 parallel adaptive multi user 初 始 化 参数 的 影响 ,我 们 来 看 一 下 当 以 很 短 的 间隔 执行 不 
呆 增 加 的 并 发 并 行 操 作 时 分 配 的 从 属 进程 数量 。 为 了 这 个 目的 ， 使 用 了 下 面 的 shell 脚 本 。 它 的 用 途 是 
以 5 秒 为 间隔 启动 20 个 并 发 的 并 行 度 为 16 ( 这 是 在 表 级 别 的 默认 值 ) 的 并 行 查询 ( 每 个 查询 运行 持续 
十 几 分 钟 ): 

sql="select * from t;" 

foriin1i123456789 1011 12 131415 16 17 18 19 20 

-S $user/$password <<<$sql & 


sleep 5 
done 


图 15-9 总 结 了 在 11.2 版 本 中 测量 的 结果 。 通 过 将 parallel adaptive_multi user 初 始 化 参数 设置 为 
FALSE ,从 属 进程 数量 在 达到 由 parallel max_servers 初 始 化 参数 的 默认 值 施 加 的 限制 (在 本 例 中 是 160 ) 
之 前 都 随 着 执行 的 并 行 操作 数量 成 比例 分 配 ( 换 句 话 说 ， 每 一 个 操作 都 运行 在 相同 的 并 行 度 下 )。 通 
过 将 parallel_adaptive_multi_user 初 始 化 参数 设置 为 TRUE， 从 9 个 并 发 的 并 行 操 作 开始 ， 并 行 度 下 降 
了 ， 因 此 ， 分 配 的 从 属 进 程 数 量 比 请 求 的 要 少 。 


@ 磁盘 IO 上 限 
磁盘 IO 上 限 是 从 11.1 版 本 开始 可 用 的 一 项 特性 。 它 的 用 途 是 根据 磁盘 IO 子 系统 能 够 支撑 的 最 大 
耕 吐 率 来 限制 默认 的 并 行 度 。 我 强调 一 下 ， 它 只 限制 默认 并 行 度 。 因 此 ， 如 果 与 默认 并 行 度 无 关 ( 例 
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如 ， 当 通过 指定 一 个 特殊 的 值 使 用 手动 并 行 度 时 )， 磁 盘 IO 上 限 根本 不 会 产生 影响 。 
磁盘 IO 上 限 对 那些 因为 不 均衡 配置 导致 的 1O 受 限 的 系统 尤为 有 用 。 在 并 行 处 理 的 情况 下 ， 一 个 
不 均衡 的 配置 经 常 意味 着 CPU 内 核 的 数量 相对 于 磁盘 IO 子 系统 能 够 支撑 的 吞吐 率 来 说 太 高 了 。 
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提示 对 于 打算 支持 大 量 并 行 SQL 语 和 句 的 数据 库 服务 器 ( 例如 ， 一 个 典型 的 用 于 数据 仓库 的 数据 库 
服务 器 ), 合理 的 配置 是 磁盘 LI/O 子 系统 能 支撑 的 符 吐 率 应 该 等 于 CPU 内 核 数量 乘 以 200 MB/s。 
例如 ， 如 果 一 个 数据 库 服务 器 有 16 个 CPU 内 核 ， 它 的 磁盘 I/O 子 系统 应 该 支撑 的 吞吐 率 为 3200 
MB/s. 


要 使 用 磁盘 1/O 上限 ,必须 满足 两 个 条 件 。 第 一 ,该 特性 必须 通过 一 个 初始 化 参数 启用 。 上 有 具体 是 哪 
一 个 取决 于 你 使 用 的 版 本 。 
口 在 11.1 版 本 中 ， 必 须 将 parallel io cap_enabled 初 始 化 参数 设置 为 TRUE ( 默认 值 是 FALSE )。 
口 从 11.2 版 本 开始 ， 必 须 将 parallel degree_limit 初 始 化 参数 设置 为 I0 ( 默认 值 是 CPU )。 注 意 ， 
从 11.2 版 本 开始 , 应 该 避免 使 用 parallel io_cap_enabled 初 始 化 参数 , 因为 它 是 不 赞成 使 用 的 。 
第 二 , 通过 IO 口径 收集 的 统计 信息 必须 能 够 被 访问 。 需 要 这 些 统计 信息 是 因为 他 们 向 数据 库 引 擎 
提供 关于 人 磁盘 1/0 子 系统 能 够 支撑 的 最 大 吞吐 率 的 信息 。 要 收集 它们 , 必须 执行 doms_resource_manager 
包 中 的 calibrate_ io 过 程 。 下 面 的 PL/SQL 代 码 块 ， 是 一 段 来 自 px_calibrate_io.sql 脚 本 的 摘录 ， 展 示 
了 如 何 执行 该 过 程 。 注 意 必须 将 num_physical disks 参 数 设 置 为 数据 库存 储 所 在 的 物理 磁盘 数量 (在 
我 的 测试 系统 上 ， 我 拥有 通过 ASM 分 配 的 十 块 磁盘 )。 
DECLARE 
1 max iops PLS INTEGER; 
1] max mbps PLS INTEGER; 


1 actual latency PLS INTEGER; 
BEGIN 
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dbms_resource manager.calibrate io( 
num physical disks => 10， 


max_iops => 1] max_iops, 
max_mbps => 1 max_mbps, 
actual latency => 1 actual latency 
); 
END; 


统计 信息 的 收集 会 持续 几 分 钟 。 一 旦 此 项 工作 结束 ,统计 信息 的 结果 就 可 以 通过 查询 
dba_rsrc_io_calibrate 视 图 呈现 出 来 。 有 两 个 值 与 磁盘 IO 上 限 有 关 : 磁盘 IO 子 系统 能 够 支撑 的 最 大 
否 吐 率 ( max_mbps ) 和 一 个 单独 的 服务 进程 能 够 支撑 的 最 大 吞吐 率 ( max_pmbps )。 在 我 的 测试 系统 上 ， 
它们 的 值 如 下 : 


SQL> SELECT max_mbps，max_pmbps 
2 FROM dba rsrc io calibrate; 


MAX_ MBPS MAX_PMBPS 


根据 上 面 的 查询 返回 的 两 个 值 ， 数 据 库 引 擎 计算 最 大 的 并 行 度 ， 如 公式 15-3 所 示 。 如 果 结 果 值 低 
于 默认 的 并 行 度 ， 它 就 成 为 新 的 默认 值 。 如 果 结 果 值 高 于 默认 的 并 行 度 ， 就 会 忽略 它 。 
公式 15-3 ”默认 并 行 度 受 到 磁盘 1/0 子 系统 能 够 支撑 的 最 大 吞吐 率 与 一 个 单独 的 服务 进程 能 够 支 
撑 的 最 大 吞吐 率 之 间 的 比率 的 限制 
max_mbps 


max_default_ dop = 
~ max_ pmbps 


@ 数据 库 资源 管理 器 
资源 管理 器 ( Resource Manager ) 对 分 配给 服务 进程 的 数据 库 资 源 提供 控制 。 除 了 其 他 功能 ， 可 
以 使 用 它 将 并 行 度 限制 为 一 个 具体 的 值 。 因 为 描述 资源 管理 器 的 细节 超出 本 章 的 范围 ( 参考 Oracle 
Database Administrator*s Guide 手 册 获 取 更 多 信息 )， 我 这 里 只 通过 px_rm_cap_dop.sql 脚 本 提供 一 个 例 
子 。 这 个 例子 展示 如 何 配置 资源 管理 器 ， 以 便 将 某 个 具体 的 用 户 所 执行 的 SQL 语句 并 行 度 限制 为 8。 
配置 步骤 如 下 所 示 。 
(1) 创建 一 个 名 为 control dop 的 资源 计划 ( resource plan ), 通过 cap_dop 消 费 者 组 ( consumer group )， 
将 并 行 度 限 制 为 8: 
BEGIN 
dbms_resource manager.create pending area(); 
dbms_resource manager.create plan( 
plan => 'CONTROL DOP', 
comment => 'Control the degree of parallelism’ 
); 
dbms_resource manager.create consumer group ( 
consumer group => 'CAP_ DOP', 
comment => 'Users with a restricted degree of parallelism' 
); 


dbms_resource manager.create plan directive( 
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plan => 'CONTROL DOP', 
group_or_subplan => 'CAP_DOP', 
comment => 'Cap degree of parallelism', 


parallel degree limit p1 => 8 
); 


dbms_resource manager.create plan directive( 


plan => "CONTROL_DOP ， 
group_or subplan => “OTHER_GROUPS ， 
comment => 'Unrestricted degree of parallelism' 


); 

dbms_resource manager.validate pending area(); 

dbms_resource manager.submit pending area(); 
END; 


(2) 提供 一 个 具有 切换 到 cap_dop 消 费 者 组 权限 的 特定 用 户 : 


BEGIN 
dbms_resource manager privs.grant switch consumer group( 
grantee_name => 'CHRIS', 
consumer group => 'CAP DOP', 
grant option => FALSE 
); 


END; 
(3) 将 一 个 具体 用 户 的 会 话 与 cap_dop 消 费 者 组 映射 : 


BEGIN 
dbms_resource manager.create pending area(); 
dbms_resource manager.set consumer group mapping( 
attribute => “ORACLE_USER ， 
value => "CHRIS', 
consumer group => 'CAP_DOP' 
); 
dbms_resource manager.submit pending area(); 
END; 


(4) 在 系统 级 别 启用 control_dop 资 源 计划 : 
ALTER SYSTEM SET resource manager plan = control dop 


z 


@ 用 户 配置 文件 

通过 用 户 配 置 文件 ( user profile ), 尤其 是 sessions per user 参 数 ， 可 以 对 具体 的 某 个 用 户 能 够 拥 
有 的 并 发 会 话 数量 做 出 限制 。 例 如 ， 下 面 的 SQL 语 句 创 建 一 个 新 的 用 户 配置 文件 ( limit dop )， 将 会 
话 的 数量 限制 为 16， 将 它 与 一 个 用 户 关联 ， 并 且 通 过 将 resource_1imit 初 始 化 参数 设置 为 TRUE ( 默认 
值 是 FALSE ) 来 启用 它 : 

CREATE PROFILE limit dop LIMIT sessions per user 16 


ALTER USER chris PROFILE limit dop 
尽管 实际 上 由 用 户 配置 文件 施加 的 限制 ,最 初 的 引入 是 为 了 防止 最 终 用 户 以 超过 某 个 指定 值 的 数 
量 并 发 登录 同一 个 数据 库 实 例 ， 该 限制 也 可 以 帮助 管理 并 行 会 话 的 数量 。 这 些 并 发 的 会 话 是 由 数据 库 
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引擎 在 一 条 SQL 语 句 并 行 执行 的 时 候 自 动 创建 的 。 该 限制 也 适用 于 它们 ， 

额外 的 会 话 被 创建 出 来 的 原因 是 ， 一 条 并 行 执行 的 SQL 语句 不 仅 需要 一 个 查询 协调 器 的 会 话 ， 而 
上 且 每 个 从 属 进 程 也 需要 一 个 会 话 。 结 果 ， 即使 一 个 最 终 用 户 只 登录 了 一 次 ， 他 也 可 能 请 求 多 个 会 话 
因此 ， 取 决 于 sessions_per_user 参 数 是 如 何 设置 的 ， 并 行 度 可 能 会 受到 限制 。 


提示 我 不 建议 使 用 用 户 配 置 文件 限制 资源 。 要 进行 限制 ， 应 该 尽量 使 用 资源 管理 器 。 我 介绍 用 户 
配置 文件 方法 仅仅 是 因为 你 需要 知道 用 户 配 置 文件 可 以 限制 并 行 度 


5. 降级 
当 查 询 协 调 器 请 求 的 从 属 进程 数量 高 于 它 实 际 可 以 获得 的 从 属 进程 数量 的 时 候 就 会 发 生 降级 。 以 
下 两 种 情况 下 会 发 生 降级 。 
口 当 并 行 度 受 到 上 一 部 分 中 描述 的 技术 限制 的 时 候 。 换 句 话 说 ， 当 并 行 度 受 到 自 适应 并 行 度 、 
资源 管理 器 ( 仅 对 于 手动 并 行 度 来 说 ) 或 用 户 配 置 文件 限制 的 时 候 。 
口 当 查 询 协调 咒 从 池 中 请 求 的 从 属 进程 数量 高 于 实际 可 用 的 从 属 进程 数量 的 时 候 ， 
事实 上 , 在 查询 协调 器 请 求 某 一 数量 的 从 属 进程 时 ， 取 决 于 已 经 在 运行 中 的 从 属 进程 有 多 少 ， 数 
据 库 引擎 可 能 无 法 满足 该 请 求 。 例 如 ， 如 果 从 属 进程 的 最 大 数量 设置 为 40， 对 于 图 15-7 中 所 示 的 执行 
计划 来 说 只 有 5 个 并 发 的 SQL 语句 (40/8 ) 能 够 通过 所 请 求 的 并 行 度 ( 请 求 8 个 从 属 进程 ) 执行 。 当 达 
到 上 限时 ， 有 以 下 三 种 可 能 性 。 
口 并 行 度 被 降级 ( 换 名 话说 ， 减 少 并 行 度 )。 
口 将 一 个 ORA-12827: insufficient parallel query slaves available 错误 返回 给 查询 协调 器 。 
口 或 者 该 SQL 语句 的 执行 计划 被 置 于 保持 状态 ， 直 到 所 需 数量 的 从 属 进程 可 用 。 
后 面 的 方法 仅 用 于 从 11.2 开 始 的 版 本 ， 而 且 仅 在 启用 语句 排队 〈 statement queuing ) 的 情况 下 (下 
一 部 分 会 介绍 此 内 容 )。 如 果 没 有 启用 语句 排队 ， 就 会 使 用 其 他 两 种 方法 中 的 一 个 。 必 须 通过 设置 
parallel_min_percent 初 始 化 参数 来 配置 具体 使 用 哪 一 种 方法 。 可 以 将 该 参数 设置 为 一 个 从 0 到 100 之 
间 的 整数 值 。 主 要 情况 有 以 下 三 种 。 
口 0: 这 个 值 ( 也 就 是 默认 值 ) 指定 可 以 被 静默 降级 的 并 行 度 。 换 句 话 说， 数据 库 引擎 能 够 提供 
尽 可 能 多 的 从 属 进程 。 如 果 可 用 的 从 属 进程 少 于 两 个 , 执行 就 会 改 为 串 行 。 这 意味 着 SQL 语句 
总 会 被 执行 ， 永 远 不 会 遇 到 ORA-12827 错 误 。 
口 1~99: 从 1 到 99 范 围 内 的 值 以 百分比 形式 为 降级 指定 一 个 限制 。 必 须 至 少 提供 达到 指定 百分比 
的 从 属 进程 ; 否则 ， 会 引发 ORA-12827 错 误 。 例 如 ， 如 果 将 它 设 置 为 25 而 且 有 会 话 请 求 16 个 
从 属 进程 ,那么 必须 至 少 提供 4 个 (16 x 25/100 ) 可 用 的 从 属 进 程 才 可 以 避免 此 错误 。 
口 100: 使 用 这 个 值 ， 要 么 提供 所 有 请 求 的 从 属 进程 ， 要么 引发 ORA-12827 错 误 。 
下 面 的 例子 (来自 px_min_percent.sql 脚 本 )， 在 没有 其 他 并 行 执 行 的 语句 运行 的 情况 下 执行 ， 证 
实 了 这 一 点 ( 注意，40 是 50 的 80% ): 
SQL> ALTER SYSTEM SET parallel max servers = 40; 


90L> ALTER TABLE 七 PARALLEL 50; 
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SQOL> ALTER SESSION SET parallel min percent = 80; 


SOL> SELECT count(pad) FROM t; 


COUNT(PAD) 


SQL> SELECT * FROM table(dbms xplan.display cursor(NULL, NULL, 'basic +parallel')); 


| Id | Operation | Name | TO |IN-OUT| PQ Distrib 
| 0 | SELECT STATEMENT | | | | 

| 1 | SORT AGGREGATE | | | | 

| 2| Px COORDINATOR | | | | 

[1 切中 PX SEND QC (RANDOM) | :TQ10000 | 0Q1,00 | P->S | QC (RAND) 
1 汤 中 SORT AGGREGATE | | 01,00 | PCWP | 

| 5| PX BLOCK ITERATOR | | 0Q1,00 | PCWC | 

| 6| TABLE ACCESS FULL| T | 0Q1,00 | PCP | 


SQL> ALTER SESSION SET parallel min percent”= 81; 


SQL> SELECT count(pad) FROM t+; 
SELECT count(pad) FROM t+ 
米 


ERROR at line 1: 
ORA-12827: insufficient parallel query slaves (requested 50, available 40, parallel min percent 81) 


如 果 想 要 知道 在 一 个 运行 中 的 数据 库 实例 上 有 多 少 个 操作 被 降级 以 及 降级 了 多 少 , 可 以 执行 下 面 
的 查询 。 显 然 ， 当 你 看 见 太 多 的 降级 ， 尤 其 是 当 很 多 操作 被 改 成 串 行 时 ， 应 该 会 怀疑 配置 的 问题 了 : 


SOL> SELECT name, value 
2 FROM v$sysstat 
3 WHERE name like “Parallel operations%"; 


NAME VALUE 
Parallel operations not downgraded 14 
Parallel operations downgraded to serial 10 
Parallel operations downgraded 75 to 99 pct 14 
Parallel operations downgraded 50 to 75 pct 2 
Parallel operations downgraded 25 to 50 pct 0 
Parallel operations downgraded 1 to 25 pct 0 


6. 语句 排队 

语句 排队 是 一 项 从 11.2 版 本 开始 可 用 的 特性 ， 旨 在 避免 降级 。 要 达到 这 一 目标 ， 资 源 管理 器 要 在 
没有 足够 可 用 的 从 属 进程 来 执行 具体 的 一 条 SQL 语 句 时 认 ee 当 资源 管理 器 识别 到 这 样 的 情 骨 外 
况 ， 它 就 会 通过 使 会 话 在 一 个 等 待 列表 中 排队 来 挂 起 该 执行 。 然 后 ， 一 旦 请 求 数量 的 从 属 进程 可 用 ， 
它 就 会 使 会 话 出 队 并 恢复 执行 。 默 认 情 况 下 ， WO 在 有 可 
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用 的 从 属 进程 之 前 会 话 必须 等 待 ( 换 句 话说 ， 这 里 没有 超时 的 概念 )。 

可 能 与 你 预期 的 相反 , 资源 管理 需 不 会 通过 比较 当前 活跃 的 从 属 进程 数量 和 数据 库 引 擎 能 够 处 理 
的 最 大 数量 ( 这 个 值 通过 parallel max_servers 初 始 化 参数 定义 ) 来 检查 是 否 有 足够 数量 的 从 属 进程 
可 用 。 相 反 ， 资 源 管理 器 使 用 男 一 个 通过 parallel servers target 初 始 化 参数 配置 的 国 值 。 使 用 这 个 
额外 的 初始 化 参数 背后 的 原因 非常 简单 : 没有 必要 为 所 有 并 行 执行 的 SQL 语 句 启用 语句 排队 。 因 此 ， 
通过 语句 排队 来 管理 仅 一 部 分 的 从 属 进 程 池 可 能 是 值得 的 。 

尽管 parallel servers_target 初 始 化 参数 是 动态 的 ， 它 也 仅 能 够 在 系统 级 别 进行 设置 。 此 外 ， 在 
12.1 多 租户 环境 下 ， 无 法 在 PDB 级 别 设置 它 。 换 句 话说 ， 对 于 从 属 进程 池 来 说 ， 该 配置 仅 能 在 数据 库 
实例 级 别 执行 。 

语句 排队 仅 在 两 种 情况 下 启用 。 第 一 ， 对 于 那些 已 将 parallel degree policy 初 始 化 参数 被 置 为 
auto 的 会 话 执行 的 SQL 语句 ( 如 果 它 们 不 包含 一 个 禁用 语句 排队 的 hint )。 第 二 ， 对 于 那些 包含 
statement_queuing hint 的 SQL 语句 。 第 二 种 可 能 性 作用 于 使 用 手动 并 行 度 的 应 用 程序 。 

对 于 那些 已 将 parallel_degree_policy 初 始 化 参数 被 置 为 auto 的 会 话 来 说 ,语句 排队 可 以 在 SQL 
语句 级 别 通 过 添加 no_statement_queuing hint 显 式 禁 用 。 

当 一 个 会 话 在 队列 中 等 待 时 ， 它 的 等 待 事 件 是 resmgr:pq queued。 例如， 下 面 的 查询 展示 哪些 会 
话 因 为 语句 排队 而 被 挂 起 了 : 

90L> SELECT sid, seconds in wait 


2 FROM v$session 
3 WHERE event = 'resmgr:pq queued'; 


SID SECONDS_ IN _ WAIT 


143 34 

挂 起 的 会 话 也 可 以 通过 v$rsrc_session_info 动 态 性 能 视图 来 监控 。 使 用 它 , 不 仅 可 以 看 见 它们 在 
队列 中 等 待 了 多 长 时 间 ( current_pq_queued time 列 ， 以 毫秒 为 单位 )， 还 可 以 知道 下 一 个 出 队 的 会 话 
是 哪 一 个 ( pq_status 列 被 设置 为 0ueue head ) 以 及 每 个 挂 起 的 会 话 请 求 的 从 属 进程 数量 ( pq_servers 
列 ) 是 多 少 。 注 意 ， 后 面 两 个 列 仅 从 12.1 版 本 开始 可 用 。 下 面 的 例子 为 上 面 查询 中 已 经 列举 的 三 个 会 
话 证 实 了 这 一 点 : 

SQL> SELECT sid, pq_status, current pq queued time, pq_servers 


2 FROM v$rsrc session info 
3 WHERE state = 'PO QUEUED'; 


SID PQ STATUS CURRENT PO QUEUED TIME PQO SERVERS 


= he 


113 Queue head 121068 16 
37 Queued 60686 16 
143 Queued 34843 4 


除了 刚刚 描述 的 默认 行为 以 外 , 资源 管理 器 还 提供 几 个 指令 , 使 用 这 些 指 令 可 以 设置 利用 以 下 特 
性 的 资源 计划 : 
口 在 等 待 列表 中 管理 会 话 的 出 队 顺 序 
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口 在 消费 组 级 别 限制 从 属 进程 的 使 用 

口 指定 超时 时 间 

口 定义 关键 SQL 语 句 以 绕 过 语句 排队 ( 仅 12.1 版 本 ) 

口 在 多 租户 环境 下 管理 语句 排队 ( 仅 12.1 版 本 ) 

关于 这 些 特性 的 详细 信息 在 Oracle Database VLDB and Partitioning Guide 手 册 中 提供 。 

7. 并 行 查询 

以 下 这 些 操 作 ， 在 查询 和 子 查 询 中 ， 都 可 以 使 用 并 行 方式 执行 : 

口 全 表 扫 描 、 全 分 区 扫描 以 及 索引 快速 全 扫描 

口 索引 全 扫描 和 范围 扫描 ， 但 是 前 提 是 索引 是 分 区 的 ( 在 一 个 给 定时 间 ， 一 个 分 区 只 能 同时 被 
一 个 从 属 进 程 访问 ， 其 副作用 是 ， 并 行 度 会 受到 访问 的 分 区 数量 的 限制 ) 

口 联接 (第 14 章 也 提供 了 一 些 例子 ) 

口 集合 操作 符 

口 排序 

口 聚合 


注意 全 表 扫 描 、 全 分 区 扫描 以 及 索引 快速 全 拉 描 在 并 行 执行 时 通常 会 使 用 直接 路 径 读 ， 因 此 ， 会 
绕 过 缓冲 区 缓存 。 一 个 例外 是 从 11.2 版 本 开始 ， 当 激活 内 存 中 的 并 行 执行 的 时 候 。 事实 上 ， 内 
存 中 执行 的 目标 恰好 是 避免 直接 路 径 读 并 缓存 尽 可 能 多 的 数据 。 注 意 对 于 索引 全 扫描 和 范围 
扫描 ， 数 据 库 引 擎 总 是 执行 正常 的 物理 读 。 


当 查 询 引用 了 不 支持 并 行 处 理 的 用 户 自 定义 函数 时 ， 它 们 无 法 通过 并 行 方式 执行 。 基 本 上 ， 要 支 
持 并 行 处 理 , 用 户 自 定义 函数 必须 既 不 能 写 人 数据 库 也 不 能 读 取 或 修改 包 变量 . 当 编写 PL/SQL 代 码 时 ， 
应 该 使 用 PARALLEL_ENABLE 子 句 标记 支持 并 行 处 理 的 用 户 自 定义 函数 。 注意 在 某 些 情况 下 用 户 定义 函数 
并 行 执行 的 能 力 不 仅 取决 于 用 户 自 定义 函数 本 身 ， 而 且 还 取决 于 调用 的 查询 ( 而 且 ， 最 终 取 决 于 执行 
计划 本 身 )，px_query_udf.sql 脚 本 提供 了 一 个 例子 ， 展示 一 个 函数 阻止 一 个 查询 以 并 行 方式 运行 ， 而 
在 男 一 个 查询 上 却 不 会 施加 这 样 的 限制 。 

并 行 查询 默认 是 启用 的 。 在 会 话 级 别 ， 可 以 使 用 下 面 的 SQL 语 句 启用 或 禁用 它们 : 

ALTER SESSION ENABLE PARALLEL OUERY 


ALTER SESSION DISABLE PARALLEL QUERY 

此 外 ， 也 可 以 在 启用 并 行 查询 的 同时 ,覆盖 由 段 级 别 的 手动 并 行 度 或 使 用 以 下 SQL 语 句 的 自动 并 
行 度 所 定义 的 并 行 度 : 

ALTER SESSION FORCE PARALLEL QUERY PARALLEL 4 

然而 ， 要 记 住 hint 要 优先 于 会 话 级 别 的 设置 。 一 方面 ， 即 使 在 会 话 级 别 禁用 了 并 行 查询 ，hint 也 可 
以 启用 一 个 并 行 执行 。 真 正 关 闭 并 行 查询 的 方法 只 有 两 个 ， 将 parallel max_servers 初 始 化 参数 设置 
为 0, 或 者 通过 配置 资源 管理 器 来 关闭 。 男 一 方面 ， 即 使 在 会 话 级 别 强制 指定 一 个 并 行 度 ，hint 也 能 引 
导 为 男 一 个 并 行 度 。 要 检查 在 会 话 级 别 是 否 启 用 了 并 行 查询 ， 可 以 执行 一 条 类 似 下 面 这 样 的 查询 
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(pq_status 列 被 设置 为 ENABLED 、DISABLE0D 或 FORCED ): 


SELECT pq_status 
FROM v$session 
WHERE sid = sys context('userenv','sid') 


下 面 的 执行 计划 展示 一 个 使 用 并 行 索引 范围 扫描 、 并 行 全 表 扫 描 以 及 并 行 散 列 联接 的 例子 。 它 来 
自 px_query.sql 肢 本。 注意 这 些 hint: parallel index hint 用 于 索引 访问 ， 而 parallel hint 用 于 表 扫描 。 
两 个 hint 都 是 使 用 对 象 级 别 语法 将 并 行 度 指定 为 2。 此 外 ，pq_distribute hint 用 于 指定 分 配方 法 。 列 TQ 
包含 三 个 值 ， 也 就 意味 着 有 三 组 从 属 进程 用 于 实施 这 个 执行 计划 。 操 作 8 以 并 行 方 式 扫描 索引 i1 ( 这 
是 可 行 的 ， 因 为 索引 是 分 区 的 )。 然 后 ， 操 作 7， 使 用 从 索引 id 提取 的 rowid， 访 问 表 t1。 如 在 操作 6 中 
所 示 ， 分 区 粒度 被 用 于 这 两 个 操作 。 接 下 来 ， 数 据 被 使 用 散 列 分 布 发 送 给 消费 者 ( 组 01,02 的 从 属 进 
程 )。 当 消费 者 接收 数据 ( 操作 4 ) 后 ， 他 们 将 数据 传递 给 操作 3 以 在 内 存 中 为 散 列 联接 构建 散 列 表 。 
一 旦 表 t1 的 数据 全 部 被 处 理 完毕 ， 表 t2 的 并 行 全 扫描 就 可 以 开始 了 。 这 是 在 操作 12 中 执行 的 。 如 在 操 
作 11 中 所 示 , 块 范围 粒度 被 用 于 此 操作 ,然后 数据 被 通过 散 列 分 布 发 送 给 消费 者 ( 组 01,02 的 从 属 进程 ) 
当 消 费 者 接收 到 数据 ( 操作 9 ) 后 ， 他 们 将 数据 传递 给 操作 3 以 探测 该 散 列表 。 最 后 ， 操 作 2 将 满足 联 
接 条 件 的 数据 发 送 给 查询 协调 器 ( 图 15-10 演 示 了 这 个 执行 计划 ): 
SELECT /#+ leading(t1) use hash(t2) 
index(t1) parallel index(t1 2) 
full(t2) parallel(t2 2) 
pq_distribute(t2 hash,hash) */ * 
FROM t1, t2 


WHERE t1.id > 9000 
AND t1.id = t2.id+1 


| Id | Operation | Name | Pstart| Pstop | TQ |IN-OUT| PQ Distri | 
| 0 | SELECT STATEMENT | | | | | | | 
| 1 | PX COORDINATOR | | | | | | | 
| 2| PX SEND OC (RANDOM) | :TQ10002 | | | 01,02 | P->S | QC (RAND) | 
|* 3 | HASH JOIN BUFFERED | | | | 01,02 | PCwP | | 
| 4a| PX RECEIVE | | | | 01,02 | PCWP | | 
| 5| PX SEND HASH | :TQ10000 | | | 01,00 | P->P | HASH | 
| 6| PX PARTITION HASH ALL | | 1 | 4 | 0Q1,00 | PCWC | | 
| 至 | TABLE ACCESS BY INDEX ROW| T1 | | | 01,00 | PCWP | | 
|*8| INDEX RANGE SCAN | I1 | | 4 | 01,00 | PCWP | | 
| 多] PX RECEIVE | | | 01,02 | PCWP | | 
| 10 | PX SEND HASH | :TQ10001 | | | 01,01 | P->P | HASH 

| 41| PX BLOCK ITERATOR | | | | 01,01 | PCNC | | 
|*12 | TABLE ACCESS FULL | 次 | | | 0Q1,01 | PCwP | | 


3 - access("T1"."ID"="T2"."ID"+1) 
8 - access("T1"."ID">9000) 
12 - filter("T2"."ID"+1>9000) 


根据 执行 计划 和 图 15-10， 使 用 了 一 个 数据 流 操作 和 三 个 表 队 列 。 注 意 ， 即 使 图 15-10 显 示 了 三 组 
从 属 进程 ( 因为 请 求 的 并 行 度 是 2， 所 以 一 共有 6 个 从 属 进 程 )， 在 执行 期 间 ， 只 有 两 组 是 从 池 中 分 配 
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的 ( 换 句 话说 ， 四 个 从 属 进程 )。 这 是 因为 一 个 单独 的 数据 流 操作 无 法 使 用 超过 两 组 的 从 属 进程 。 这 
个 特殊 的 例子 中 会 出 现 的 情况 是 用 于 扫描 表 t1 (01,00 ) 的 那 一 组 永远 不 会 与 扫描 表 t2 (01,01 ) 的 那 
一 组 同时 并 发 运行 。 因 此 ， 查 询 协调 器 简单 地 为 这 两 组 (重复 ) 使 用 相同 的 从 属 进程 。 


ay 
图 15-10 尽管 出 现 了 三 组 从 属 进 程 ， 一 个 单独 的 数据 流 操作 
也 无 法 使 用 超过 两 组 的 从 属 进程 执行 


警告 HASH JOIN BUFFERED 操 作 ( 在 上 面 的 执行 计划 中 ， 操 作 3 ) 不 仅 创 建 一 张 包含 构建 的 输入 ( 操 
作 5 到 8 ) 返回 的 数据 的 散 列表 ， 而 且 还 会 缓存 由 满足 联接 条 件 的 探测 输入 ( 操作 10 到 操作 12 ) 
返回 的 数据 。 因 此， 就 有 了 后 组 BUFFERED。 这 是 数据 库 引 擎 因为 内 部 限制 〈 两 种 分 布 操作 
无 法 在 同一 时 间 被 激活 ) 不 得 不 实现 的 一 种 特殊 行为 。 从 性 能 的 角度 来 看 ， 缓 冲 可 能 会 是 一 
个 重大 问题 。 


8. 并 行 DML 语 句 

以 下 DML 语 句 可 以 使 用 并 行 方式 执行 : 

口 DELETE 

口 带 有 子 查 询 的 INSERT ( 带 有 VALUES 子 句 的 INSERT 语 名 无 法 被 并 行 化 ) 
口 MERGE 

口 UPDATE 


注意 ” INSERT 语句 和 MERGE 语 句 ( 对 于 插入 数据 的 部 分 ) 并 行 执行 的 时 候 使 用 直接 路 径 插 入 。 因 此 ， 
它们 不 仅 受 到 直接 路 径 插 入 的 优势 和 劣势 的 影响 ， 而 且 也 受到 直接 路 径 插 入 的 限制 条 件 的 制 
约 。 我 会 在 15.4 节 介绍 它们 。 


在 以 下 情况 下 DML 语句 无 法 通过 并 行 方式 执行 : 
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口 某 张 表 上 有 触发 器 ; 

口 某 张 表 有 一 个 引用 自身 的 外 键 约束 ,或 者 有 一 个 带 有 级 联 删 除 的 外 键 约束 ,或 者 有 一 个 延迟 
约束 ; 

口 它们 是 在 一 个 分 布 式 事务 中 执行 的 ; 

口 它们 引用 了 一 个 远程 对 象 ; 

口 它们 引用 了 一 个 无 法 并 行 执行 的 用 户 自 定义 函数 ( 在 PL/SQL 中 ， 使 用 PARALLEL_ENABLE 子 句 来 
标记 支持 并 行 处 理 的 函数 ); 

口 修改 了 某 个 对 象 列 ; 

口 或 修改 了 某 个 群集 或 临时 表 。 

并 行 DML 语 句 默认 是 禁用 的 (小 心 ， 此 处 与 并 行 查询 正好 相反 )。 在 会 话 级 别 ， 可 以 通过 以 下 的 

SQL 语句 启用 和 禁用 它们 ; 
ALTER SESSION ENABLE PARALLEL DML 


ALTER SESSION DISABLE PARALLEL DML 

此 外 ,也 可 以 通过 以 下 SQL 语句 强制 并 行 执行 来 使 用 某 个 具体 的 并 行 度 : 

ALTER SESSION FORCE PARALLEL DML PARALLEL 4 

自 12.1 版 本 起 , 还 可 能 用 enable _parallel dml 和 disable parallel dml hint 来 启用 和 禁用 并 行 DML 
语句 。 与 并 行 查询 会 出 现 的 情况 形成 对 照 的 是 ， 只 使 用 parallel 和 parallel index hint 无 法 启用 并 行 
DML 语 句 。 换 句 话 说, DML 语 名 如果 要 利用 并 行 处 理 只 能 在 会 话 级 别 或 SQL 语句 级 别 启用 。 要 检查 并 
行 DML 语 句 在 会 话 级 别 是 处 于 启用 还 是 禁用 状态 ， 可 以 执行 类 似 以 下 的 查询 ( pdml_status 列 被 设置 
为 ENABLED 、DISABLED 或 FORCED ): 


SELECT pdml] status 
FROM v$session 
WHERE sid = sys_context('userenv','sid') 


除了 INSERT 语 名 ,必须 同时 启用 并 行 查 询 以 支持 使 用 并 行 方 式 执行 DML 语 句 。 事实 上 ,， DML 语句 
基本 是 由 两 个 操作 组 成 : 首先 找到 要 修改 的 数据 ， 然 后 第 二 步 才 是 修改 它们 。 问 题 是 如 果 查 找 数 据 的 
部 分 不 是 以 并 行 方式 执行 的 ， 则 无 法 并 行 化 修改 数据 的 部 分 。 为 了 验证 这 种 行为 ,我 们 来 看 几 个 来 自 
px_dml.sql 脚 本 的 例子 。 
口 仅 启 用 并 行 DML 语 句 时 ， 没 有 一 个 操作 是 并 行 化 的 : 
SOL> ALTER SESSION DISABLE PARALLEL QUERY; 
SQL> ALTER SESSION ENABLE PARALLEL DML; 
SQOL> ALTER TABLE 七 PARALLEL 2; 


SQL> UPDATE t SET id = id + 1; 


| 0 | UPDATE STATEMENT | 
| 1 | UPDATE | T 
| 2| TABLE ACCESS FULL| T 
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口 仅 启用 并 行 查询 时 ，DML 语 句 的 更 新 部 分 没有 以 并 行 方式 执行 。 事 实 上 ， 只 有 操作 3 到 操作 5 
是 由 从 属 进程 执行 的 。 因 此 ， 更 新 部 分 (操作 1 ) 是 由 查询 协调 融 串 行 执行 的 : 


SOL> ALTER SESSION ENABLE PARALLEL QUERY; 
S0L> ALTER SESSION DISABLE PARALLEL DML; 
SQL> ALTER TABLE 七 PARALLEL 2; 
SQL> UPDATE t SET id = id + 1; 


| Id | Operation | Name | TO |IN-OUT| PQ Distrib | 


| 0 | UPDATE STATEMENT | | | | | 
| 1 | UPDATE 和 T | | | | 
| 2| PX COORDINATOR | | | | | 
| 3| PX SEND QC (RANDOM)| :TQ10000 | 01,00 | P->S | QC (RAND) | 
| 4| PX BLOCK ITERATOR | | 01,0o | PCAC | | 
| 5| TABLE ACCESS FULL| T | Q1,00 | PCwP | | 


口 同时 启用 并 行 查询 和 并 行 DML 语 名 时， 更 新 部 分 ( 操作 3 ) 以 并 行 方 式 执行 。 在 此 情况 下 ， 只 
使 用 了 一 组 从 属 进 程 〈 操作 2 到 操作 5 在 To 列 上 拥有 相同 的 值 )。 这 暗示 每 个 从 属 进程 扫描 各 自 
的 表 分 区 粒度 并 修改 它 所 找到 的 记录 : 

SQL ALTER SESSION ENABLE PARALLEL QUERY; 


SQL> ALTER SESSION ENABLE PARALLEL DML; 
SQL> ALTER TABLE 七 PARALLEL 2; 
SQL> UPDATE t SET id = id + 1; 


Id Operation | Name | TQ |IN-OUT| PQ Distrib | 
0 | UPDATE STATEMENT | | | 
1 | PX COORDINATOR | | | | | 
2 PX SEND QC (RANDOM) | :TQ10000 | 0Q1,00 | P=>S | QC (RAND) | 
3 UPDATE [并 | 0Q1,00 | PCAP | | 
4 | PX BLOCK ITERATOR | | 01,00 | PCWwc | | 
5 TABLE ACCESS FULL| T | 0Q1,00 | PCwP | | 


9. 并 行 DDL 语 句 

表 和 索引 支持 并 行 DDL 语 句 。 以 下 是 三 个 有 代表 性 的 并 行 化 操作 : 

口 CREATE TABLE ... AS SELECT ... (CTAS ) 语句 

口 索引 的 创建 和 重建 

口 约束 的 创建 和 验证 

此 外 ， 对 于 已 分 区 表 和 索引 ， 还 可 以 并 行 化 类 似 COALESCE 、MOVE 和 SPLIT 这 样 的 分 区 管理 操作 。 通 
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常 ， 可 利用 并 行 处 理 的 DDL 请 句 会 提供 PARALLEL 子 句 (很 快 你 就 会 看 到 ， 约束 是 一 个 例外 ) 来 指定 是 
否 应 该 使 用 并 行 处 理 ， 以 及 如 果 使 用 了 并 行 处 理 ， 其 并 行 度 是 多 少 。 
默认 会 启用 并 行 DDL 语 句 。 在 会 话 级 别 ， 可 以 使 用 下 面 的 SQL 话 句 启 用 或 禁用 它们 : 


ALTER SESSION ENABLE PARALLEL DDL 


ALTER SESSION DISABLE PARALLEL DDL 

也 可 以 通过 使 用 下 面 的 SQL 语句 以 某 个 特定 的 并 行 度 强制 并 行 执行 ( 对 于 支持 它 的 DDL 语 句 来 
说 ): 

ALTER SESSION FORCE PARALLEL DDL PARALLEL 4 

要 检查 是 否 在 会 话 级 别 启用 或 禁用 了 并 行 DDL 语 句 , 可 以 执行 类 似 下 面 的 查询 ( pddl_status 列 被 
设置 为 ENABLED 、DISABLED 或 FORCED ): 


SELECT pddl_status 
FROM v$session 
WHERE sid = sys_context('userenv','sid') 


对 于 可 以 并 行 执行 的 这 三 种 主要 DDL 语 名 类 型 ， 接 下 来 的 几 个 部 分 将 会 展示 几 个 基于 px _dd1.sql 
脚本 的 例子 。 
@ CTAS 语 名 
一 条 CTAS 语 句 是 由 两 个 处 理 数据 的 操作 组 成 : 用 于 从 来 源 表 中 检索 数据 的 查询 操作 和 向 目标 表 
插入 数据 的 插入 操作 。 每 个 部 分 都 可 以 独立 于 彼此 使 用 串 行 或 并 行 方 式 执 行 。 但 是 ， 如 果 使 用 了 并 行 
处 理 , 一 般 会 将 两 个 操作 都 并 行 化 。 下 面 的 执行 计划 演示 了 这 一 点 。 
口 插入 并 行 化 : 只 有 操作 2 至 操作 4 是 以 并 行 方 式 执行 的 。 查 询 协调 器 扫描 表 t1 并 使 用 循环 方法 
( round-robin ) 将 它 的 内 容 分 发 给 从 属 进 程 。 既 然 查询 协调 器 和 多 个 从 属 进程 通信 ， 这 些 操作 
之 间 的 关系 就 是 串 行 到 并 行 ( S->P )。 一 组 从 属 进程 接收 这 些 数据 并 以 并 行 方式 执行 插入 ( 操 
作 LOAD AS SELECT ) : 


CREATE TABLE t2 PARALLEL 2 AS SELECT /*+ no parallel(t1) */ * FROM t1 


| Id Operation | Name | TQ |IN-OUT| PQ Distrib | 
| 0 | CREATE TABLE STATEMENT | | | 
| 1 | PX COORDINATOR | | | 
| 到 PX SEND QC (RANDOM) | :TQ10001 | 0Q1,01 | P->S | QC (RAND) | 
| 3 LOAD AS SELECT | | 01,01 | PCWP | 
| 和 汝 PX RECEIVE | | Q1,01 | PCWwP | 
| 5 PX SEND ROUND-ROBIN| :TQ10000 | S->P | RND-ROBIN | 
| -站 TABLE ACCESS FULL | T1 | | | 


口 查询 并 行 化 : 只 有 操作 3 至 操作 5 是 以 并 行 方式 执行 的 。 从 属 进 程 基 于 块 范围 粒度 以 并 行 方式 
扫描 表 t1 并 将 其 内 容 发 送 给 查询 协调 器 ， 这 就 是 并 行 到 串 行 (P->S ) 关系 的 原因 。 查 询 协 调 器 
执行 插入 (操作 LOAD AS SELECT ): 

CREATE TABLE t2 NOPARALLEL AS SELECT /*+ parallel(t1 2) */ * FROM t1 
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Id Operation | Name TO |IN-OUT| PQ Distrib 
0 | CREATE TABLE STATEMENT | | 
1 LOAD AS SELECT | T2 | | 
2 PX COORDINATOR | | 
3 PX SEND QC (RANDOM) | :TQ10000 Q1,00 | P->S | QC (RAND) 
4 PX BLOCK ITERATOR | Q1,00 | PCWC 
5 TABLE ACCESS FULL | T1 Q1,00 | PCWP 


口 两 个 操作 全 部 并 行 化 :从属 进 程 基 于 块 范围 粒度 以 并 行 方 式 扫 描 表 t1 并 直接 将 它们 获得 的 数 
据 插 和 人 到 目标 表 中 ， 不 需要 将 数据 发 送 给 另 一 个 并 行 从 属 组 。 应 该 注意 两 件 重要 的 事情 ， 第 
一 ,查询 协调 器 并 没有 直接 参与 数据 的 处 理 。 第 二 ， 数 据 并 没有 通过 表 队 列 发 送 (除了 由 操 
作 2 发 送 给 查询 协调 器 的 少量 信息 ， 没 有 发 生 任何 通信 ): 

CREATE TABLE t2 PARALLEL 2 AS SELECT /*+ parallel(t1 2) */ * FROM t1 


Id Operation | Name TQ |IN-OUT| PQ Distrib 
0 | CREATE TABLE STATEMENT | | 
1 | PX COORDINATOR | | 
2 PX SEND OC (RANDOM) | :TQO10000 | 01,00 | P->S | OC (RAND) 
3 LOAD AS SELECT | WT 01,00 | PCWP 
4 PX BLOCK ITERATOR | Q1,00 | PCWC 
3 TABLE ACCESS FULL | T1 Q1,00 | PCWP 


上 面 的 例子 展示 了 实用 对 象 级 别 语法 的 hint。 要 为 两 个 操作 都 启用 并 行 化 ( 最 后 一 个 例子 ), 从 11.2 
版 本 开始 ， 对 于 CTAS 语 句 可 以 使 用 语句 级 别 的 语法 ， 如 下 例 所 示 : 

CREATE /*+ parallel(2) */ TABLE t2 AS SELECT * FROM tl 

与 之 前 的 那 一 种 相 比 ， 使 用 这 种 语法 的 一 个 重要 的 区 别 就 是 ， 因 为 没有 指定 PARALLEL 子 句 ， 并 行 
度 只 用 于 表 的 创建 阶段 。 换 句 话 说， 在 数据 字典 中 ,与 这 张 表 关联 的 并 行 度 是 1。 


@ 索引 的 创建 和 重建 

可 以 通过 并 行 方式 创建 和 重建 索引 。 要 完成 创建 过 程 ， 需 要 两 组 从 属 进程 合作 。 第 一 组 读 取 被 索 
引 的 数据 。 第 二 组 对 其 从 第 一 组 接收 的 数据 进行 排序 并 建立 索引 。 下 面 的 SQL 语句 是 一 个 例子 。 注 意 
第 一 组 如 何 执行 操作 6 到 操作 8 (01,00 ) 以 及 第 二 组 如 何 执行 操作 2 到 操作 5 (0Q1,01 )。 数 据 是 以 范围 方 
法 在 这 两 组 进程 之 间 进 行 分 布 的 《所 以 第 二 组 的 每 个 并 行 子 进 程 处 理 它 分 配 到 的 索引 的 一 小 部 分 )， 
而 且 拥 有 一 个 并 行 到 并 行 (P->P ) 的 关系 : 

CREATE INDEX i1 ON t1 (id) PARALLEL 4 


| 0 | CREATE INDEX STATEMENT | | | | | 
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1 PX COORDINATOR | 

2 PX SEND QC (ORDER) | :TQ10001 | 01,01 | P->5 | QC (ORDER) 
3 INDEX BUILD NON UNIQUE| I1 Q1,01 | PCWP 

4 SORT CREATE INDEX | 01,01 | PCWP 

5 PX RECEIVE | 01,01 | PCWP 

6 PX SEND RANGE | :TQ10000 01,00 | P->P | RANGE 

7 PX BLOCK ITERATOR | 01,00 | PCWC 

8 TABLE ACCESS FULL| T1 01,00 | PCWP 


索引 的 重建 也 会 引导 出 十 分 类 似 的 执行 计划 ( 注意 根据 操作 8， 数 据 是 从 索引 中 提取 的 ， 而 不 是 
从 表 中 ): 


ALTER INDEX i1 REBUILD PARALLEL 4 


| Id Operation Name | TQ |IN-OUT| PQ Distrib | 
| 0 | ALTER INDEX STATEMENT | | | | 
1 PX COORDINATOR | | | 
| 2| PX SEND QC (ORDER) :TQ10001 | 0Q1,01 | P->S | QC (ORDER) | 
| 各 INDEX BUILD NON UNIOUE I1 | 01,01 | PCWP | 
| 4 SORT CREATE INDEX | 01,01 | PCWP | 
| 5 PX RECEIVE | 01,01 | PCWP | 
| §& PX SEND RANGE :TQ10000 | 0Q1,00 | P->P | RANGE | 
| ， 洒 PX BLOCK ITERATOR | | Q1,00 | PCWC | 
| & INDEX FAST FULL SCAN| I1 | Q1,00 | PCWP | 


@ 约束 的 创建 和 验证 

创建 或 验证 约束 〈 例如 外 键 和 检查 约束 ) 时 ， 必 须 验证 已 经 存储 在 表 中 的 数据 。 出 于 这 个 目的 ， 
数据 库 引擎 执行 一 个 递归 查询 。 例 如 ， 假 设 执行 下 面 的 SQL 语句 : 

ALTER TABLE t ADD CONSTRAINT t id nn CHECK (id IS NOT NULL) 

数据 库 引 擎 递归 地 执行 类 似 下 面 这 样 的 查询 来 验证 存储 在 表 中 的 数据 ( 注意 ,如果 查询 返回 结果 
为 空 ， 数 据 就 是 有 效 的 ): 

SELECT rowid 


FROM +t 
WHERE NOT (id IS NOT NULL) 


因此 ， 如 果 约 束 创 建 所 属 的 表 拥 有 值 为 2 或 更 高 的 并 行 度 ， 数 据 库 引擎 会 以 并 行 方式 执行 该 查询 。 


注意 ”在 表 级 别 定义 的 并 行 度 用 于 递归 查询 ， 与 在 会 话 级 别 是 否 局 用 、 禁 用 或 强制 并 行 查询 和 并 行 
DDL 语 名 没有 关系 。 换 和 句 话 说 ，ALTER SESSION ..，PARALLEL 语 名 对 递归 查询 没有 影响 。 


定义 主键 约束 时 ,数据 库 引 擎 无 法 以 并 行 方式 创建 索引 。 为 避免 这 个 限制 ， 必 须 在 定义 约束 之 前 
创建 ( 唯一) 索引 。 下 面 的 SQL 语句 进行 了 演示 : 
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CREATE UNIQUE index t pk ON t (id) PARALLEL 2 


ALTER TABLE t ADD CONSTRAINT t pk PRIMARY KEY (id) 


15.3.2 ” 何 时 使 用 


并 行 处 理 只 有 在 满足 两 个 条 件 时 才 应 该 被 使 用 。 第 一 ， 在 有 大 量 可 用 的 空闲 资源 ( CPU、 内 存 ， 
及 磁盘 IO 带宽 ) 的 情况 下 可 以 使 用 该 技术 。 记 住 , 并行 处 理 的 目标 是 通过 将 一 个 通常 由 单独 的 进程 ( 此 
时 也 就 会 使 用 一 个 单独 CPU 内 核 ) 所 做 的 工作 分 散 给 多 个 进程 ( 此 时 就 会 使 用 多 个 CPU 内 核 ) 以 减少 
响应 时 间 。 第 二 ， 可 以 为 那些 使 用 串 行 方式 执行 超过 十 几 秘 钟 的 SQL 语句 使 用 该 技术 ; 否则 ， 并 行 环 
境 ( 主要 是 从 属 进 程 和 表 队列 ) 初始 化 、 协 调和 终止 所 需 的 时 间 及 资源 ， 可 能 会 比 从 并 行 化 本 身 获 益 
的 还 要 高 一 些 。 实 际 使 用 时 的 限制 取决 于 可 用 的 资源 总 量 。 因 此 ,在 某 些 情况 下 ， 只 有 那些 花费 超过 
几 分 钟 的 SQL 语句 ， 或 甚至 更 长 时 间 的 语句 ， 才 适合 使 用 并 行 执行 。 值 得 注意 的 是 ， 如 果 这 两 个 条 件 
不 满足 ， 性 能 恐怕 会 不 升 反 降 。 

如 果 经 常 对 很 多 的 SQL 语句 使 用 并 行 处 理 ， 应 该 在 系统 级 别 启 用 自动 并 行 度 ， 或 者 在 段 级 别 启用 
手动 并 行 度 。 否 则 ， 如 果 它 仅 用 于 特定 的 批 处 理 或 报表 ， 一 般 来 说 最 好 是 在 会 话 级 别 通过 hint 启 用 它 
比较 好 。 


15.3.3 ”陷阱 和 请 误 


有 一 点 你 需要 明白 ,在 对 象 级 别 语法 中 使 用 parallel 和 parallel index 这 两 个 hint， 并 不 会 强制 查 
询 优 化 占 使 用 并 行 处 理 。 反 而 ， 它 们 会 履 盖 在 表 或 索引 级 别 上 定义 的 并 行 度 。 因 此 ， 添 加 这 两 个 hint 
会 允许 查询 优化 器 使 用 指定 的 并 行 度 来 考虑 并 行 处 理 。 这 意味 着 查询 优化 器 会 分 别 在 使 用 和 不 使 用 并 
行 处 理 的 情况 下 考虑 执行 计划 ， 并 且 按 照 惯例 ， 从 中 选 出 具有 较 低 成 本 的 那 一 个 。 接 下 来 我 会 通过 展 
示 一 个 来 自 px_dop_manual.sql 脚 本 的 例子 来 加 深 你 的 印象 。 如 下 面 的 SQL 语 句 所 示 ,， 与 全 表 扫 描 关联 
的 成 本 随 着 并 行 度 成 比例 下 降 ( 参考 第 7 章 ， 获 取 更 多 关于 并 行 操作 成 本 的 信息 ): 


SQL> EXPLAIN PLAN SET STATEMENT ID 'dop1' FOR 
2 SELECT /*+ full(t) parallel(t 1) */ * FROM t WHERE id > 93000; 


SOL> EXPLAIN PLAN SET STATEMENT ID 'dop2' FOR 
2 SELECT /*+ full(t) parallel(t 2) */ * FROM t WHERE id > 93000; 


SOL> EXPLAIN PLAN SET STATEMENT ID 'dop3' FOR 


2 SELECT /*+ full(t) parallel(t 3) */ * FROM t WHERE id > 93000; 


SOL> EXPLAIN PLAN SET STATEMENT ID “dop4”FOR 


2 SELECT /*+ full(t) parallel(t 4) */ * FROM t WHERE id > 93000; 


SQL> SELECT statement id, cost 
2 FROM plan table 
3 WHERE id = 0; 


STATEMENT ID COST 
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dop2 164 
dop3 110 
dop4 82 


如 果 该 SQL 语句 在 没有 hint 并 且 并 行 度 设置 为 1 的 情况 下 执行 ,查询 优化 器 会 选择 索引 范围 扫描 : 
SQL> SELECT * FROM t WHERE id > 93000; 


| Id | Operation | Name | Cost (%CPU) | 
| 0 | SELECT STATEMENT | | 125 (0)| 
| 1| TABLE ACCESS BY INDEX ROWID| T | 125 (0)| 
|* 2 | INDEX RANGE SCAN [ 工 1 村 全 


2 - access("ID">93000) 
注意 ， 与 上 面 执行 计划 关联 的 成 本 ( 125 ) 要 低 于 使 用 并 行 度 为 2 时 的 全 表 扫描 成 本 。 相 较 而 言 ， 
使 用 大 于 或 等 于 3 的 并 行 度 时 ， 全 表 扫 描 的 成 本 更 低 一 些 ， 
现在 ， 我 们 来 看 一 下 仅 将 parallel hint 添 加 到 SQL 语句 时 会 发 生 什么 ， 换 句 话 说， 就 是 不 使 用 访 
问 路 径 hint 时 。 结 果 是 当 并 行 度 设置 为 2 的 时 候 ， 查 询 优 化 器 选择 了 串 行 的 索引 范围 扫描“， 而 当 并 行 度 
设置 为 3 的 时 候选 择 了 并 行 全 表 扫 描 : 
SQL> SELECT /*+ parallel(t 2) */ * FROM t WHERE id > 93000; 


| Id | Operation | Name | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 325 (0)| 
| 1 | TABLE ACCESS BY INDEX ROWID| T | 125 (0)| 
|* 2 | INDEX RANGE SCAN [|I | 17 (0)| 


2 - filter("ID">93000) 
SQL> SELECT /*+ parallel(t 3) */ * FROM t WHERE id > 93000; 


0 | SELECT STATEMENT | 
1 | PX COORDINATOR | 
2 | PX SEND OC (RANDOM)| 
3| PX BLOCK ITERATOR | 
4 | TABLE ACCESS FULL| T 


| 
| 
:TQ10000 | 110 (1)| 
| 
| 


4 - filter("ID">93000) 
总 之 ，parallel 和 parallel_index 这 两 个 hint 只 是 简单 地 允许 查询 优化 器 考虑 并 行 处 理 ; 它们 不 会 
强制 查询 优化 器 做 什么 。 
为 了 让 并 行 化 的 执行 更 高 效 , 将 工作 总 量 在 所 有 的 从 属 进程 中 间 进 行 平均 分 配 十 分 关键 。 事 实 上 ， 
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所 有 属于 一 个 组 的 从 属 进程 , 在 同 组 内 的 所 有 从 属 进程 都 执行 完毕 之 前 必须 处 于 等 待 状态 , 简 而 言 之 ， 
并 行 操作 的 速度 取决 于 最 慢 的 那个 从 属 进程 。 如 果 想 要 检查 一 条 SQL 语句 工作 量 的 实际 分 布 情况 ， 你 
既 可 以 使 用 实时 监控 ( 参见 第 4 章 ), 也 可 以 使 用 v$pq_tqstat 动 态 性 能 视图 。 基 本 上 , 该 视图 对 于 每 一 
个 从 属 进程 以 及 执行 计划 中 的 每 一 个 PX SEND 和 PX RECEIVE 操 作 都 会 显示 一 行 记 录 。 需 要 注意 这 个 信息 
只 会 提供 当前 会 话 以 及 最 近 以 并 行 方式 成 功 执行 的 SQL 语句 。 我 们 来 看 一 个 例子 ， 这 个 例子 来 自 
px_tqstat.sql 脚 本 生成 的 输出 。 两 份 输出 之 间 的 映射 是 通过 执行 计划 的 TQ 列 以 及 v$pq_tqstat 视 图 的 
dfo_number 列 和 tq_id 列 来 完成 的 。 那 么 要 记 住 , 与 之 前 解释 的 一 样 , 执行 计划 显示 关于 生产 者 的 信息 。 
例如 ，01,00 对 应 dfo_number 等 于 1 并 且 tq_id 等 于 0 的 记录 。 此 外 ，PX SEND 操 作对 应 生产 者 ，PX RECEIVE 
操作 对 应 消费 者 : 
SQLx SELECT * FROM t t1, t 2 WHERE ti id = £2 1d; 


Id Operation Name pstart| Pstop | TO |IN-OUT| PQ Distrib | 
0 | SELECT STATEMENT | 
1 PX COORDINATOR | | 
2 PX SEND OC (RANDOM) :TO10001 | 0Q1,01 | P->s | QC (RAND) | 
水 党 | HASH JOIN | 0Q1,01 | PCNP 
4 PX RECEIVE | Q1,01 | PCAP 
5 PX SEND PARTITION (KEY)| :TQ10000 | | 01,00 | P->p | PART (KEY) 
6 | PX BLOCK ITERATOR I 2 | 01,00 | PCWC 
于 TABLE ACCESS FULL T 1 2 | 0Q1,00 | PCWP 
8 PX PARTITION HASH ALL 下 2 | 01,01 | PCWC 
9 TABLE ACCESS FULL 1 2 | 01,01 | PCWP 


3 - access("T1"."ID"="T2","ID") 


SQL> SELECT dfo number, tq_id, server type, process, Num rows, bytes 
2 FROM v$pq_tqstat 
3 ORDER BY dfo number, tq id, server type DESC, process; 


DFO NUMBER TQ ID SERVER TYP PROCES NUM ROWS BYTES 
1 0 Producer P002 29042 3136278 
4 0 Producer PO03 70958 7673358 
1 0 Consumer ”Poo0 20238 2188357 
el 0 Consumer Poo01 79762 8621279 
下 1 Producer ”Po00 20238 4376714 
1 1 Producer Poo1 79762 17242534 
4 1 Consumer QC 100000 21619248 


上 面 的 输出 给 出 了 以 下 信息 。 

口 操作 5 通过 从 属 进程 P002 发 送 了 29 042 条 记录 ， 而 通过 P003 发 送 了 70 958 条 记录 。 

口 操作 4 接收 到 由 操作 5 发 送 的 数据 : 通过 从 属 进程 P000 发 送 的 20238 条 ,以 及 通过 从 属 进程 P001 
发 送 的 79 762 条 记录 ,这 显示 了 在 这 个 特定 的 案例 中 , 基于 分 区 键 的 分 布 运行 得 并 不 是 很 理想 。 

口 操作 2 通过 从 属 进程 P000 发 送 给 查询 协调 器 20 238 条 记录 ， 并 通过 从 属 进程 P001 发 送 了 79 762 
条 记录 。 作 为 上 一 次 分 布 的 结果 ， 这 一 次 依旧 是 不 理想 的 。 
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口 操作 1， 也 就 是 由 查询 优化 器 执行 的 操作 ， 接 收 到 100 000 条 记录 。 

每 个 从 属 进程 都 打开 了 它们 自己 到 数据 库 实 例 之 间 的 会 话 。 这 意味 着 如 果 想 要 监控 或 跟踪 一 条 单 
独 的 SQL 语句 执行 的 处 理 过 程 ， 你 没 办 法 将 注意 力 集中 在 单独 的 一 个 会 话 上 。 因 此 ， 你 要 么 使 用 一 个 
类 似 于 实时 监控 这 样 的 工具 ， 以 便 为 你 整合 来 自 多 个 会 话 的 执行 统计 信息 ,要 么 就 需要 亲自 动手 做 这 
件 事 。 举 例 来 说 ,通过 SQL 跟踪 ,每 个 从 属 进程 都 会 生成 其 自己 的 跟踪 文件 ( 在 这 样 的 情形 下 TRCSESS 
命令 行 工 具 可 能 有 所 帮助 )。 与 此 有 关 的 一 个 主要 问题 是 因为 当前 实现 的 限制 ， 查 询 协调 器 会 忽略 为 
其 工作 的 从 属 进程 的 执行 统计 信息 。 下 面 由 dbms_xplan 生 成 的 执行 计划 证 实 了 这 一 点 。 注 意 除 了 由 查 
询 协 调 器 执行 的 操作 ( PX COORDINATOR ) 以 外 ，Starts 、A-Rows 以 及 Buffers 这 些 列 的 值 是 都 被 设置 为 0: 

SQL> SELECT * FROM table(dbms xplan.display cursor('6j5z013saaz9r' ,0,'iostats last')); 


Id Operation Name Starts | A-Rows | Buffers | 
0 | SELECT STATEMENT 1 | 100K | | 

1 | PX COORDINATOR 下 100K| 16 | 

2 | PX SEND OC (RANDOM) :TQ10001 0 | 0 | 0 | 

* 3 HASH JOIN 0 | 0 | 0 | 
4 | PX RECEIVE 0 | 0 | 0 | 

5 | PX SEND PARTITION (KEY)| :TQ10000 0 | 0 | 0 | 

6 PX BLOCK ITERATOR 0 | 0 | 0 | 

* 了 | TABLE ACCESS FULL T | 0 | 0 | 0 | 
| 8| PX PARTITION HASH ALL | | 0 | 0 | 0 | 
| 9| TABLE ACCESS FULL | T | 0 | 0 | 0 | 


当 处 理 库 缓存 中 的 游标 时 ， 一 个 可 行 的 解决 方案 是 不 将 format 参 数 的 值 指定 为 ljast。 事 实 上 ， 如 
果 SQL 语 句 只 执行 了 一 次 (可 以 通过 查看 PX COORDINATOR 操作 的 Starts 列 来 检查 )， 你 会 看 见 所 有 由 从 
属 进程 执行 的 工作 总 和 。 遗憾 的 是 , 在 使 用 了 多 个 数据 流 操 作 的 执行 计划 中 , 这 个 解决 方案 不 会 奏效 ， 
或 者 当 处 于 一 个 RAC 环 境 中 时 , 从 属 进程 的 一 部 分 是 在 一 个 或 多 个 远程 实例 中 分 配 的 时 候 也 不 会 有 作 
用 。 下 面 的 例子 ， 显示 了 与 上 一 个 例子 中 相同 的 子 游标 ， 演 示 了 它 起 作用 的 一 个 案例 : 


SQL> SELECT * FROM table(dbms xplan.display cursor('6j5z013saaz9r' ,0,'iostats')); 


| Id | Operation | Name | Starts | A-Rows | Buffers | Reads | 
| 0 | SELECT STATEMENT | | 1 | 100K | 16 0 | 
| 1 | PX COORDINATOR | | | 100K 16 0 
| 2| PX SEND OC (RANDOM) | :TQ10001 | 0 0 0 0 
|* 3| HASH JOIN | | 2 100K 2719 2464 
和， PX RECEIVE | | p] 100K 0 0 
| 51 PX SEND PARTITION (KEY)| :TO10000 | 0 0 0 0 
| 6| PX BLOCK ITERATOR | | 2 100K| 2767 2464 
Ie 票 】 TABLE ACCESS FULL | T | 26 100K| ”2767 2464 
| 8| PX PARTITION HASH ALL | | 2 100K| 2719 2464 
| 9 | TABLE ACCESS FULL | T | 2 100K| 2719 2464 


执行 并 行 DML 语 句 的 会 话 ( 而 且 仅 对 于 那个 会 话 而 言 ; 对 于 其 他 会 话 , 未 提交 的 数据 甚至 不 可 见 ) 
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在 不 提交 (或 回 深 ) 事务 的 情况 下 无 法 访问 修改 的 表 。 此 时 提交 (或 回 深 ) 之 前 执行 的 SQL 语句 会 引 
发 一 个 ORA-12838: cannot read/modify an object after modifying it in parallel 错 误 而 终止 。 下 面 
是 一 个 例子 ( 注意 ，UPDATE 语 句 是 并 行 化 的 ): 

SQL> UPDATE t SET id = id + 41; 


SQL> SELECT count(#) FROM tt; 
SELECT count(*) FROM 七 
米 


ERROR at line 1: 
ORA-12838: cannot read/modify an object after modifying it in parallel 


SOL> COMMIT; 
SOL> SELECT count(*) FROM tt; 
COUNT(*) 


100000 
还 有 一 个 与 上 面 这 个 限制 类 似 的 情况 ， 当 一 个 并 行 DML 请 句 试 图 修改 一 个 曾经 被 串 行 DML 语 句 
修改 过 的 对 象 时 ， 会 引发 一 个 ORA-12839: cannot modify an object in parallel after modifying 让 
错误 。 下 面 是 一 个 例子 ( 注意 SELECT FOR UPDATE 语句， 为 了 设置 行 锁 ， 必 须 修 改 这 张 表 ): 
SQL> SELECT id FROM 七 WHERE rownum = 1 FOR UPDATE; 


SQL> UPDATE t SET id = id + 1; 
UPDATE t SET id = id+1 
米 


ERROR at line 1: 
ORA-12839: cannot modify an object in parallel after modifying it 


SOL> COMMIT; 
SQL> UPDATE 七 SET id = id + 1; 


100000 rows updated. 


15.4 直接 路 径 插入 


Oracle 数 据 库 提 供 两 种 将 数据 加 载 到 表 中 的 方法 ( 假设 该 表 不 是 存储 在 一 个 群集 中 ): 传统 插入 和 
直接 路 径 插 入 。 传 统 插 入 ， 与 其 名 称 所 示 含 义 一 样 ， 就 是 通常 使 用 的 那 一 种 。 而 数据 库 引 擎 只 有 在 被 
明确 要 求 的 情况 下 才 会 使 用 直接 路 径 插 入 。 直接 路 径 插 入 的 目标 是 高 效 加 载 大 量 数据 ( 对 于 小 数据 量 ， 
使 用 直接 路 径 时 的 性 能 可 能 会 比 使 用 传统 插入 时 更 低 )。 直接 路 径 插 入 能 够 实现 高 性 能 插入 ， 是 因为 
它 的 实现 是 以 牺牲 功能 为 代价 来 换取 最 优 的 性 能 。 出 于 这 个 原因 ， 与 使 用 传统 插入 相 比 ， 使 用 直接 路 
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径 插 入 时 会 遇 到 更 多 的 要 求 和 限制 。 在 本 节 中 , 我 会 讨论 直接 路 径 插 入 如 何 工 作 ， 什么 时 候 适 合 使 用 
这 种 技术 ,以 及 与 之 有 关 的 一 些 陷 阱 和 诬 误 。 


注意 ”要 加 载 数据 CTAS 语 句 ， 请 使 用 直接 路 径 插入 


15.4.1 工作 原理 


可 以 通过 指定 一 个 hint， 或 可 以 通过 使 用 某 个 特定 功能 来 启用 直接 路 径 插入 。 启 用 方式 有 以 下 几 
种 可 能 性 。 
口 在 INSERT INTO ... SELECT .. .语句 (包括 多 重 插 入 ) 和 MERGE 诸 句 ( 对 于 插入 数据 的 部 分 ) 中 
指定 append hint: 
INSERT /*+ append */ INTO ... SELECT ... 
口 在 使 用 “普通 ”VALUES 子 句 的 INSERT 语 名 中 指定 append hint ( 仅 在 11.1 版 本 中 有 效 ): 
INSERT /*+ append */ INTO ... VALUES (...) 
口 在 使 用 “普通 ”VALUES 子 句 的 INSERT 语 句 中 指定 append_values hint ( 仅 从 11.2 版 本 开始 有 效 ): 
INSERT /*+ append values */ INTO ... VALUES (...) 
口 以 并 行 方式 执行 INSERT INTO ... SELECT .. .语句 。 注 意 在 这 种 情况 下 ， 可 以 分 别 并 行 化 INSERT 
和 SELECT。 要 利用 直接 路 径 插 入 功 有 ， 至 少 INSERT 部 分 必须 要 并 行 化 。 
口 直接 使 用 OCTI 直 接 路 径 接口 ,或 通过 使 用 一 个 OCI 直 接 路 径 接口 的 应 用 程序 ( 例如 , SQL*Loader 
实用 工具 )。 
如 果 需 要 对 一 条 自动 启用 了 该 功能 的 SQL 语句 禁用 直接 路 径 插 入 〈 例如， 一 条 并 行 执行 的 INSERT 
INTO ... SELECT ... 语 句 )， 可 以 指定 noappend 这 个 hint。 
为 改善 效率 ， 直 接 路 径 插入 会 直接 在 被 修改 段 的 高 水 位 线 以 上 使 用 直接 路 径 写 来 加 载 数据 ,通过 
这 种 方式 来 提高 性 能 。 这 个 事实 的 存在 有 重要 的 意义 。 
口 缓冲 区 缓存 ， 因 为 直接 写 的 原因 ， 被 绕 过 了 。 
口 并 发 的 DELETE 、INSERT 、MERGE 以 及 UPDATE 语 句 ， 与 在 修改 的 段 上 建立 (或 重建 ) 的 索引 一 样 ， 
是 不 被 允许 的 。 当 然 ， 为 保证 这 一 点 ， 段 锁 (segment lock ) 会 被 获取 。 
口 在 高 水 位 线 以 下 包含 的 空闲 空间 块 不 在 考虑 范围 之 内 。 这 意味 着 即使 为 了 清除 数据 而 执行 了 
DELETE 语 句 ， 段 的 大 小 还 是 会 不 断 地 增 大 。 
直接 路 径 插 入 能 够 带 来 更 好 性 能 的 一 个 原因 是 ， 对 于 表 段 来 说 只 会 生成 最 少量 的 undo。 事 实 上 ， 
只 有 空间 管理 操作 才 会 少量 生成 undo ( 例如 ， 为 了 增加 高 水 位 线 以 及 向 段 中 增加 新 的 内 容 )， 而 对 于 
那些 通过 直接 路 径 插 入 存储 到 数据 块 中 的 记录 来 说 ， 则 不 会 生成 undo。 但 是 ， 如 果 表 上 有 索引 ， 对 于 
索引 段 来 说 一 般 又 会 生成 undo。 如 果 你 还 想 要 避免 与 索引 段 相 关 的 undo， 可 以 在 加 载 之 前 禁用 索引 并 
在 加 载 完毕 后 重建 索引 。 尤 其 是 在 ETL 任 务 中 ， 这 是 实践 中 常用 的 操作 。 而 且 大 家 喜欢 这 样 做 的 另 一 
个 原因 是 ， 让 数据 库 引 擎 在 加 载 结束 时 自行 维护 索引 可 能 不 如 重建 索引 来 得 更 快 。 
为 进一步 改进 性 能 ， 还 可 以 使 用 最 小 化 日 志 (minimal logging )。 最 小 化 日 志 的 目的 是 最 小 化 redo 
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的 生成 。 这 个 操作 是 可 选 的 ,但 是 通常 它 对 于 大 幅 减 少 响应 时 间 的 作用 十 分 明显 。 可 以 通过 在 表 或 分 
区 级 别 设置 nologging 参 数 来 指示 数据 库 引擎 使 用 最 小 化 日 志 。 一 定 要 理解 最 小 化 日 志 仅 支持 直接 路 径 
插入 和 一 部 分 DDL 语 句 。 事 实 上 ，redo 总 是 会 为 所 有 操作 生成 。 要 知道 对 于 存储 在 群集 中 的 表 ， 最 小 
化 日 志 无 能 为 力 。 


注意 ”只 有 在 已 经 完全 理解 指定 nologging， 也 就 是 最 小 化 redo 生 成 的 影响 的 时 候 ， 你 才 可 以 这 样 做 . 
事实 上 ， 对 于 使 用 最 小 化 日 志 修改 的 块 ， 无 法 执行 介质 恢复 。 这 意味 着 如 果 执行 了 介质 恢复 ， 
数据 库 引 擎 只 能 将 那些 使 用 了 nologging 的 块 标记 为 逻辑 损坏 ， 因 为 介质 恢复 需要 访问 redo 信 
息 以 便于 重 构 块 的 内 容 ， 而 这 对 于 nologging 的 块 是 不 可 能 的 ， 因 为 之 前 提 到 使 用 最 小 化 日 志 
时 redo 信 息 是 不 会 存储 下 来 的 ,因此 ,访问 包含 这 些 块 的 对 象 的 SQL 语 句 会 引发 一 个 ORA-26040: 
Data block was loaded using the NOLOGGING option 错 误 而 终止 。 因 此 ， 应 该 仅 在 以 下 情况 下 
使 用 最 小 化 日 志 : 能 够 手动 重新 加 载 数据 ， 或 愿意 在 加 载 完毕 后 执行 一 个 备份 ， 或 者 可 以 承 
担 丢 失 数 据 的 风险 。 


图 15-11 展 示 了 一 个 你 可 以 通过 直接 路 径 插入 实现 的 改进 的 例子 ,这 些 数据 是 我 在 测试 系统 上 通过 
启动 dpi_performance.sql 这 个 脚本 测量 出 来 的 。. 
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常规 插入 直接 路 径 插入 Nologging 模 式 下 
直接 路 径 插入 


图 15-11 在 使 用 和 不 使 用 直接 路 径 搬 入 的 情况 下 加 载 数据 的 对 比 〈 没 有 索引 的 表 ) 


注意 , 在 图 1$-11 中 ， 对 于 两 种 直接 路 径 插 入 ，undo 的 生成 都 是 可 以 忽略 不 计 的 。 这 是 因为 被 修改 
的 表 没 有 索引 。 图 15-12 展 示 了 同样 的 测试 在 适当 的 位 置 使 用 了 主键 时 的 数据 。 不 出 所 料 , 为 索引 段 生 
成 了 undo。 
直接 路 径 插入 不 像 传统 插入 那样 支持 所 有 对 象 。 它们 的 功能 是 受 限 的 。 如 果 数 据 库 引擎 无 法 执行 直 加 
接 路 径 插入 ， 则 该 操作 默认 会 转化 成 为 一 个 传统 插入 。 当 遇 到 下 列 条件 之 一 的 时 候 就 会 发 生 这 种 情况 。 
口 已 启用 的 INSERT 触 发 器 出 现在 修改 的 表 上 。( 注意 ，DELETE 和 UPDATE 触 发 器 对 直接 路 径 插 入 没 
有 影响 ) 


口 已 启用 的 外 键 出 现在 要 修改 的 表 上 ( 指向 修改 表 的 其 他 表 的 外 键 没 有 问题 ) 

口 修改 的 表 是 索引 组 织 表 。 

口 修改 的 表 存 储 在 群集 中 。 

口 修改 的 表 包 含 对 象 类 型 的 列 

口 修改 的 表 拥 有 一 个 通过 非 唯一 索引 维护 的 主 〈 或 唯一 ) 键 。 从 11.1 版 本 开始 ， 这 个 限制 不 复 
存在 。 
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图 15-12 在 使 用 和 不 使 用 直接 路 径 插 入 的 情况 下 加 载 数据 的 对 比 ( 带 有 主键 的 表 ) 


15.4.2 ” 何 时 使 用 


一 旦 需要 加 载 大 量 的 数据 ， 而 且 适 用 于 直接 路 径 插 入 的 那些 限制 条 件 对 你 来 说 不 是 问题 的 时 候 ， 
就 应 该 使 用 直接 路 径 插入 。 

如 果 提 高 性 能 是 你 的 主要 目的 ， 你 可 能 还 需要 考虑 使 用 最 小 化 日 志 (nologging )。 然而， 正如 之 
前 解释 过 的 ， 只 有 在 完全 理解 并 接受 这 样 做 的 影响 ,并且 你 能 够 采取 必要 的 措施 来 保证 不 在 处 理 过 程 
中 损失 数据 的 情况 下 ， 才 可 以 使 用 此 选项 。 


15.4.3 ”陷阱 和 请 误 


即使 没有 使 用 最 小 化 日 志 ， 在 noarchivelog 模 式 下 运行 的 数据 库 也 不 会 为 直接 路 径 搬入 生成 redo。 

如 果 数 据 库 或 表 空 间 处 于 force logging 模 式 下 , 对 存储 在 其 中 的 段 使 用 最 小 化 日 志 是 不 可 能 的 。 事 
实 上 , force logging 会 覆盖 nologging 人 参数 。 注意 当 使 用 类 似 或 Streams 这 样 的 主 从 复制 特性 的 时 候 , force 
logging 尤 其 有 用 。 为 了 能 够 成 功 运用 这 些 技术 ， 重 做 日 志 中 需要 包含 关于 所 有 数据 修改 的 信息 

在 直接 路 径 插 入 期 间 ， 高 水 位 线 并 不 增长 。 只 有 提交 事务 的 时 候 才 会 执行 增长 的 操作 。 因 此 ， 执 
行 直 接 路 径 插 入 的 会 话 ( 而 且 仅 对 于 此 会 话 ; 对 于 其 他 的 会 话 ， 高 水 位 线 以 上 的 未 提交 数据 甚至 不 可 
见 )， 在 加 载 完 毕 后 在 不 提交 (或 回 深 ) 事务 的 情况 下 无 法 访问 修改 的 表 。 在 提交 (或 回 滚 ) 之 前 执 
行 的 SQL 语句 会 伴随 着 一 个 ORA-12838: cannot read/modify an object after modifying it in parallel 
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错误 而 终止 。 下 面 是 一 个 例子 : 
SOL> INSERT /*+ append */ INTO t SELECT * FROM t; 


SOL> SELECT count(*) FROM t; 
SELECT count(*) FROM +t 
水 


ERROR at line 1: 
ORA-12838: cannot read/modify an object after modifying it in parallel 


SQL> COMMIT; 
SQL> SELECT count(*) FROM t; 


COUNT(*) 


与 ORA-12938 错 误 有 关 的 文本 可 能 会 令 人 迷惑 ， 因 为 即使 没有 使 用 并 行 处 理 也 会 这 样 生成 。 


15.5 行 预 取 


当 一 个 应 用 程序 从 数据 库 中 提取 数据 ， 它 可 以 逐 行 提取 ， 或 者 使 用 更 好 的 方式 , 同时 提取 很 多 行 。 
同时 提取 很 多 行 称 作 行 预 取 ( row prefetching )。 


15.5.1 工作 原理 


行 预 取 的 概念 简单 明确 。 应 用 程序 每 次 请 求 驱 动 程序 从 数据 库 中 检索 一 行 数据 ， 都 有 多 出 来 的 行 
通过 行 预 取 被 预 取出 来 ， 存 放 在 客户 端 内 存 中 。 这 种 方式 下 ， 后 续 几 个 请 求 不 需要 再 次 执行 数据 库 访 
问 来 提取 数据 。 检 索 数 据 可 以 由 客户 端 内 存 直接 提供 。 因 此 ,往返 数据 库 的 次 数 随 着 预 取 行 的 数量 成 
比例 下 降 。 所 以 ,检索 包含 很 多 行 数据 的 结果 集 时 的 负载 可 能 会 大 为 减少 。 作 为 一 个 例子 ， 图 15-13 
向 你 展示 在 将 预 提 取 的 行 数 增加 至 50 的 时 候 ， 检 索 100 000 行 数据 的 响应 时 间 。 这 个 测试 使 用 了 
RowPrefetchingPerf.java 文 件 中 的 Java 类 。 

40 


30 


响应 时 间 ( 秒 ) 


0 10 20 30 40 50 
行 预 取 的 数量 
图 15-13 ”检索 包含 很 多 行 数据 的 结果 集 ， 所 需 的 时 间 强 烈 依 赖 于 预 提取 行 的 数量 
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一 定 要 理解 在 不 使 用 行 预 取 时 ( 也 就 是 说 ， 逐 行 处 理 )， 检 索 的 不 良性 能 表现 并 非 是 由 数据 库 引 
人 擎 引起 的 。 相 反 ， 这 是 由 应 用 程序 自己 引起 的 ， 并 因此 承担 后 果 。 在 查看 为 非 预 取 的 案例 使 用 SQL 跟 
踪 生 成 的 执行 统计 信息 后 ， 原 因 就 更 明显 了 。 下 面 的 执行 统计 信息 显示 ， 虽 然 客 户 端 花费 了 大 概 持续 
37 秒 钟 的 时 间 (参见 图 15-13 )， 但 其 中 只 有 2.3 秒 是 花费 在 处 理 数据 库 端 的 查询 上 ! 
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call count 
Parse 1 
Execute 外 
Fetch 100001 
total 100003 


即便 行 预 取 对 于 客户 端 来 讲 更 加 重要 ,但 数据 库 也 能 从 中 获 益 。 事 实 上 , 行 预 取 极 大 地 减少 了 退 
辑 读 的 数量 ( 从 100 004 下 降 到 3542 )。 下 面 的 执行 统计 信息 显示 当 预 取 50 行 的 时 候 减 少 的 逻辑 读数 量 : 


elapsed disk query current 
0.00 0 0 0 
0.00 0 0 0 
2.30 213 100004 0 
2.30 213 100004 0 


100000 


call count 
Parse vl 
Execute pl 
Fetch 2001 
total 2003 


接 下 来 的 小 节 提 供 一 些 关于 如 何在 使 用 PL/SQL 、OCI、JDBC、ODPNET 以 及 PHP 时 利用 行 预 取 
的 基础 知识 .除了 由 每 个 API 提 供 的 功能 以 外 , 从 12.1 版 本 开始 ,有 一 个 应 用 程序 设置 的 值 可 以 被 Oracle 
客户 端 目录 下 的 $TNS_ADMIN/oraaccess.xm1l 配 置 文件 覆盖 。 注 意 因为 它 是 一 个 客户 端 配 置 文件 ， 所 以 
PL/SQL 引 擎 不 受 它 的 影响 。 但 不 管 怎样 ， 通 过 OCI 库 连接 的 所 有 应 用 程序 都 会 受 其 影响 。 下 面 的 例子 
展示 如 何 为 所 有 的 连接 设置 行 预 取 值 为 100: 


elapsed disk query current 
0.08 0 0 0 
0.00 0 0 0 
0.13 665 3542 0 
0.21 665 3542 0 


<?xml] version="1.0" encoding="ASCII" ?> 
<oraaccess xmlns="http://xmlns.oracle.com/oci/oraaccess" 
xmlns:oci="http://xmlns.oracle.com/oci/oraaccess" 
schemalLocation="http://xmlns.oracle.com/oci/oraaccess 


<default parameters> 


<prefetch> 


《IOWS>100</IOWS> 


</prefetch> 


</default parameters> 


</oraaccess> 


http://xmlns.oracle.com/oci/oraaccess.xsd"> 


名 话说 ， 数 据 库 版 本 无 关 紧要 。 


关于 $TNS_ADMIN/oraaccess.xml 配 置 文 件 的 详细 信息 ， 请 参考 Oracle Call Interface Programmer”s 
Guide 手 册 。 


100000 


注意 ”要 利用 $TNS_ADMIN/oraaccess.xm1 配 置 文件 ， 只 要 求 客户 端 可 执行 文件 必须 是 12.1 版 本 的 。 换 
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1,.PL/SQL 
如 果 在 编译 时 将 plsql_optimize_level 初 始 化 参数 设置 为 2 ( 默认 值 ) 或 更 高 ， 则 行 预 取 会 用 于 游 
标 FOR 循 环 。 举 个 例子 ， 下 面 PL/SQL 代 码 块 中 的 查询 每 次 预 提取 100 行 数据 : 


BEGIN 
FOR c IN (SELECT * FROM 七 ) 
LOOP 
-- process data 
NULL ; 
END LOOP; 
END; 


注意 ” 预 提取 的 行 数 无 法 进行 更 改 。 


一 定 要 记 住 行 预 取 仅 会 自动 用 于 FOR 循 环 游标 。 要 在 其 他 类 型 的 游标 中 使 用 行 预 取 , 必须 使 用 BULK 
COLLECT 子 句 。 此 处 展示 它 在 一 个 隐 式 游标 中 的 使 用 方式 : 


DECLARE 
TYPE t t IS TABLE OF t%ROWTYPE; 
上 
BEGIN 
SELECT * BULK COLLECT INTO 1 +t 
FROM tt; 
FOR i IN 1 t.FIRST..1 t.LAST 
LOOP 
-- process data 
NULL; 
END LOOP; 
END; 


通过 上 面 的 PL/SQL 代 码 块 , 会 在 单独 的 一 次 提取 中 返回 结果 集 的 所 有 行 。 如果 行 的 数量 很 多 , 会 
需要 大 量 的 内 存 。 因 此 ， 在 实践 中 ， 除 非 你 知道 即将 要 返回 的 行 数量 是 做 过 限制 的 ， 否则 就 应 该 使 用 
LIMIT 子 句 为 单独 的 一 次 提取 设置 一 个 限制 。 下 面 的 PL/SQL 代 码 块 展示 如 何 一 次 提取 100 行 数据 ; 


DECLARE 
CURSOR 性 IS SELECT *% 下 RON 二 
TYPE t t IS TABLE OF t%ROWTYPE; 
本 


FETCH c BULK COLLECT INTO 1 t LIMIT 100; 
EXIT WHEN 1 t.COUNT = 0; 
FOR 3 TN TFIRSTsad LEAST 
LOOP 
-- process data 
NULL; 
END LOOP; 
END LOOP; 
CLOSE cc; 
END; 
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dbms_sql 包 、 本 地 动态 SQL 以 及 RETURNING 子 句 都 支持 行 预 取 。 然而 , 如 在 之 前 的 两 个 例子 中 所 示 ， 
必须 显 式 启用 ( 例如， 使 用 BULK COLLECT ) 行 预 取 。 


2..00| 

使 用 OCI, 行 预 取 是 由 两 个 属性 控制 的 : 0CI_ATTR_PREFETCH_ROWS 和 和 OCI _ATTR_PREFETCH_MEMORY。 
前 者 限制 提取 的 行 数量 。 后 者 限制 用 于 提取 行 的 内 存 总 量 ( 按 字 节 计 )。 下 面 的 代码 片段 展示 如 何 调 
用 0CIAttrSet 函 数 来 设置 这 些 属性 。 完 整 的 例子 由 row_prefetching.c 文 件 中 的 C 程 序 提供 : 


ub4 rows = 100; 


OCIAttrSet(stm, // 语 身 可 柄 
OCI_HTYPE_STMT, // 被 修改 的 句柄 类 型 
&rows， // 特性 的 值 
sizeof(ITows )， // 特性 的 值 的 大 小 
OCI_ATTR_PREFETCH_ROWS，// 要 设置 的 特性 
err); // 错误 句柄 

Ub4 memory = 10240; 

OCIAttrSet (stm, // 语句 和 句柄 
OCI_HTYPE_STMT, // 被 修改 的 句柄 类 型 
&memory， // 特性 的 值 
sizeof(memory), // 特性 的 值 的 大 小 
OCI ATTR_PREFETCH_MEMORY，// 要 设置 的 特性 
err); // 错误 句柄 

同时 设置 两 个 属性 时 , 首先 达到 的 那个 限制 会 被 执行 。 要 关 掉 行 预 取 , 必须 将 两 个 属性 都 设置 为 0 

3. JDBC 


Oracle JDBC 驱 动 程序 默认 情况 下 会 启用 行 预 取 。 你 可 以 通过 两 种 方式 变更 提取 行 的 默认 数量 
( 10 ), 第 一 种 是 当 通 过 0racleDataSource 或 0racleDriver 类 打开 一 个 到 数据 库 引 擎 的 连接 时 指定 一 个 属 
性 。 下 面 的 代码 片段 作为 例子 展示 如 何 为 一 个 0racleDataSource 对 象 设置 用 户 名 、 密 码 ， 以 及 预 提取 
的 行 数量 。 注 意 ， 在 本 例 中 ， 因 为 它 被 设置 为 1， 所 以 行 预 取 被 禁用 了 : 


connectionproperties = new Properties(); 
connectionproperties.put(OracleConnection.CONNECTION PROPERTY USER NAME, user); 
connectionPproperties.put(OracleConnection.CONNECTION PROPERTY_PASSWORD, password); 
connectionproperties.put(OracleConnection.CONNECTION PROPERTY DEFAULT_ ROW PREFETCH, "1"); 
dataSource.setConnectionProperties(connectionProperties); 


第 二 种 方式 是 在 连接 级 别 通 过 使 用 java.sql.Statement 或 java.sql.ResultSet 接 口 ( 以 及 它们 的 子 
接口 ) 的 setFetchsize 方 法 来 覆盖 默认 值 。 下 面 的 代码 片段 展示 使 用 setFetchsize 方 法 将 提取 的 行 数 
量 设置 为 100 的 例子 。RowPrefetching.java 文 件 中 的 Java 程 序 提供 了 完整 的 例子 : 


Sql = "SELECT id, pad FROM t"; 
statement = connection.prepareStatement(sql); 
statement.setFetchSize(100); 
resultset = statement.executeQuery(); 
while (resultset.next()) 
{ 
id = resultset.getLong("id"); 
pad = resultset.getString("pad"); 
// 过 程 数据 
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resultset.close(); 
statement.close(); 


4. ODP.NET 

ODP.NET 的 默认 提取 大 小 ( 65 536 ) 是 按 字 节 定 义 的 ， 而 不 是 按 行 定义 。 可 以 通过 0racleCommand 
和 OracleDataReader 类 提供 的 Fetchsize 属 性 来 更 改 这 个 值 。 下 面 的 代码 片段 是 如 何 设置 该 属性 的 值 以 
达到 提取 100 行 的 一 个 例子 。 注 意 如 何 使 用 0racleCommand 类 的 RowSize 属 性 计算 存储 100 行 数据 所 需 的 
内 存 总 量 。RowPrefetching.cs 文 件 中 的 C# 程 序 提供 一 个 完整 的 例子 : 

sql = "SELECT id, pad FROM t"; 

command = new OracleCommand(sql, connection); 

reader = command.ExecuteReader(); 

reader.FetchSize = command.RowSize * 100; 


while (reader.Read()) 
{ 


id = reader.GetDecimal(0); 
pad = reader.GetString(1); 
// 过 程 数据 
reader.Close(); 2 
从 10.2.0.3 版 本 的 ODPNET 开 始 ， 也 可 以 通过 下 面 的 注册 表 条 目 来 更 改 默 认 提取 大 小 
(<Assembly Version> 是 0racle.DataAccess.dl1 的 完整 版 本 号 ): 
HKEY_ LOCAL MACHINE\SOFTWARE\ORACLE\ODP.NET\<Assembly Version>\Fetchsize 


5..PHR 

在 PECL OCI8 扩 展 程序 中 默认 是 启用 行 预 取 的 。 可 以 通过 两 种 方式 更 改 默认 的 提取 行 的 数量 ( 100; 
直到 该 扩展 的 1.3.3 版 本 , 它 一 直 是 10 )。 第 一 种 是 通过 设置 php.ini 配 置 文件 中 的 oci8.default_prefetch 
选项 来 更 改 默认 值 。 第 二 种 是 在 语句 级 别 通 过 在 解析 和 执行 阶段 之 间 调 用 oci_set_prefetch 函 数 来 覆 
盖 默 认 值 。 下 面 的 代码 片段 是 一 个 如 何 设置 此 值 以 提取 100 行 数据 的 例子 。RowPrefetching.php 脚 本 提 
供 一 个 完整 的 例子 : 

$sql = "SELECT id, pad FROM t"; 

$statement = oci parse($connection, $sq1); 

oci set prefetch($statement, 100); 

oci execute($statement, OCI NO AUTO COMMIT); 

while ($row = oci fetch assoc($statement)) 


{ 
$id = $row[ 'ID']; 
$pad = $row['PAD']; 
// 过 程 数 据 


oci free statement($statement); 


15.5.2” 何 时 使 用 
不 管 怎样 ， 当 需要 提取 的 数据 超过 一 行 的 时 候 ， 使 用 行 预 取 就 是 合理 的 。 
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15.5.3 ”陷阱 和 廖 误 


当 使 用 OCTI 库 的 时 候 , 并 非 总 是 能 够 完全 禁用 行 预 取 。 举 个 例子 , 使 用 JDBC OCI 驱 动 程序 或 使 用 
SQL*Plus， 提取 行 数量 的 最 小 值 是 2。 在 实践 中 ， 这 不 会 成 为 问题 ， 至 于 为 什么 可 能 还 会 有 一 些 疑 惑 ， 
例如 ， 尽 管 在 SQL*Plus 中 将 arraysize 系 统 变 量 设置 为 1， 你 还 是 会 看 到 有 两 行 数据 被 提取 了 。 

比如 说 ， 如 果 一 个 应 用 程序 一 次 显示 10 行 数据 ， 一 般 来 说 从 数据 库 中 提取 100 行 是 没有 意义 的 。 
预 提 取 的 行 数 应 该 尽 可 能 与 应 用 程序 在 特定 的 时 间 点 需要 的 行 数 相 匹配 。 


15.6 ”数组 接口 


前 面 的 章节 展示 了 当 一 个 应 用 程序 从 数据 库 中 提取 数据 的 时 候 ， 它 可 以 逐 行 提取 ,或 者 使 用 更 好 
的 做 法 通过 行 预 取 提 取 多 行 。 同 样 的 理念 也 适用 于 应 用 程序 向 数据 库 引 警 发 送 数据 时 的 情况 ,或 者 换 
名 话说， 在 输入 变量 的 绑 定期 间 。 此 时 ， 数 组 接口 (array interface ) 就 可 以 派 上 用 场 了 


15.6.1 工作 原理 


使 用 数据 接口 可 以 绑 定 数组 而 非 标量 值 。 当 某 个 特定 的 DML 语 句 需要 插入 或 修改 大 量 数据 时 , 这 
个 特性 尤其 有 用 。 不 用 为 每 一 行 记录 单独 执行 该 DML 语 句 ， 你 可 以 将 所 有 必要 的 值 绑 定 为 一 个 数组 ， 
并 且 仅 需要 执行 一 次 , 或 者 如 果 行 的 数量 很 大 ， 可 以 将 执行 拆 分 为 多 个 小 一 些 的 批 次 。 这 样 ， 到 数据 
库 的 往返 次 数 就 会 随 着 数组 的 大 小 成 比例 的 减少 ,图 15-14 展 示 通 过 将 数组 的 大 小 提高 到 50 的 时 候 插 入 
100 000 行 数据 的 响应 时 间 。 此 测试 使 用 了 ArrayInterfacePerf.java 文 件 中 的 Java 类 。 
50 


0 10 20 30 40 50 
数组 大 小 (记录 数 ) 


图 15-14 ”向 数据 库 加 载 数 据 所 需 的 时 间 强 烈 依赖 于 每 次 执行 所 处 理 的 行 数 


一 定 要 理解 在 不 使 用 数组 处 理 ( 也 就 是 逐 行 处 理 ) 的 情况 下 ， 加 载 的 不 良性 能 表现 并 非 在 于 数据 
库 引 擎 。 相 反 ， 这 是 由 应 用 程序 自身 引起 的 ， 并 因而 承担 后 果 。 通 过 查看 使 用 SQL 跟踪 生成 的 执行 统 
计 信息 ， 可 以 很 明显 地 发 现 这 一 点 。 下 面 的 执行 统计 信息 显示 ， 虽 然 客 户 端 花费 了 持续 超过 50 秒 的 时 
间 ( 见 图 15-14 ), 但 其 中 只 有 3.1 秒 是 花费 在 数据 库 端 对 插入 的 处 理 上 : 


call count cpu elapsed disk query current TOWS 
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Execute 100000 3.06 3.10 2 2075 114173 100000 
Fetch 0 0.00 0.00 0 0 0 0 
total 100001 3.06 3:10 2075 114173 100000 


尽管 数组 接口 对 于 客户 端 来 说 更 加 高 效 ， 但 是 数据 库 引 擎 也 同样 从 中 获 益 。 事 实 上 ， 数 组 接口 减 
少 了 逻辑 读 的 数量 ( 从 116 248 下 降 到 18 143 )。 下 面 的 执行 统计 信息 显示 以 50 为 批 次 插入 数据 时 减少 
的 逻辑 读数 量 : 


call count cpu elapsed disk query current ITOWS 
Parse 0.00 0.00 0 0 0 0 
Execute 2000 0.26 0.38 0 刘 32 15011 100000 
Fetch 0 0.00 0.00 0 0 0 0 
total 2001 0.26 0.38 0 3132 15011 100000 


下 面 的 小 节 提 供 一 些 关于 如 何在 使 用 PL/SQL、OCI、JDBC 以 及 ODPNET 时 利用 数组 接口 的 基础 
知识 。 注 意 ， 在 PHP 中 ， 对 于 PECL OCI8 扩 展 程序 ， 是 不 支持 数组 接口 的 。 但 根据 使 用 PHP 开 发 的 应 
用 程序 类 型 ， 我 认为 这 不 是 一 个 大 问题 。 


1. PL/SQL s 

要 在 PL/SQL 中 使 用 数组 接口 , 可 以 使 用 FORALL 语 句 。 通 过 它 , 可 以 执行 一 条 使 用 绑 定数 组 向 数 
据 库 引擎 传递 数据 的 DML 语 句 。 下 面 的 PL/SQL 代 码 块 展示 如 何在 单独 的 一 次 执行 中 插入 100 000 行 数 
据 。 注 意 ， 代 码 的 第 一 部 分 仅 用 于 准备 数组 。 带 有 INSERT 语 句 的 FORALL 语 名 本身 仅 占用 了 PL/SQL 代 码 
块 中 的 最 后 两 行 : 


DECLARE 
TYPE t id IS TABLE OF t.id%TYPE; 
TYPE t pad IS TABLE OF 七 .pad%TYPE ; 
了 
1 pad t pad := t pad(); 
BEGIN 
-- prepare data 
1 id.extend(100000); 
1 pad.extend(100000); 
FOR i IN 1..100000 


LOOP 

1 ia %= 省 

1 pad(i) = zpad( 100, * )3 
END LOOP; 


-- insert data 
FORALL i IN 1 id.FIRST..1 id.LAST 
INSERT INTO t VALUES (1 id(i), 1 pad(i)); 
END; 


一 定 要 注意 ， 即 使 该 语法 是 基于 FORALL 关 键 字 的 ， 这 也 并 不 是 一 个 循环 。 所 有 的 数据 行 是 在 单独 
的 一 次 数据 库 调 用 中 发 送 的 。 
数组 接口 受 支 持 的 情况 不 止 此 一 种 ， 还 有 dbms_sql 包 以 及 本 地 动态 SQL 也 支持 它 。 
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2. OCI 

要 通过 OCI 利 用 数组 接口 ， 不 需要 具体 的 郴 数 。 事 实 上 ， 用 于 绑 定 变量 的 郴 数 0CIBindByPos 和 
0CIBindByName ， 以 及 用 于 执行 SQL 语句 的 函数 0CIStmtExecute ， 都 可 以 使 用 数组 作为 参数 。 
array_interface.c 文 件 中 的 C 程 序 提供 了 一 个 例子 。 


3. JDBC 

要 通过 JDBC 利 用 数组 接口 ， 可 以 使 用 批量 更 新 。 如 下 面 的 代码 片段 所 示 ， 在 单独 的 一 次 执行 中 
插入 100 000 行 数据 ， 可 以 通过 执行 addBatch 方 法 将 一 次 “执行 ”添加 到 一 个 批 次 中 。 当 包含 多 个 “ 执 
行 ” 的 整个 批 次 准备 就 绪 ， 可 以 通过 执行 executeBatch 方 法 向 数据 库 引 擎 提交 该 批 次 数据 。 两 个 方法 
都 在 java.sql.Statement 接口 中 提供 ， 而 且 因 此 ， 也 在 子 接口 java.sql.PreparedStatement 和 
java.sql.Callablestatement 中 提供 。 完 整 的 例子 由 ArrayInterface.java 文 件 中 的 Java 程 序 提供 : 

sql = "INSERT INTO t VALUES (?, 7)"; 


statement = connection.prepareStatement(sql); 
for (int i=1 ; i<=100000 ; i++) 


statement.setInt(1, i); 
statement ,setString(2; "sa. Some text 。..")3 
statement .addBatch(); 

} 


counts = statement.executeBatch(); 
statement.close(); 


警告 根据 JDBC 标 准 ，java.sql.Statement 接 口 以 及 它 的 子 接口 java.sql.PreparedStatement 和 
java.sq1.Callablestatement 都 支持 批量 更 新 。 尽 管 Oracle 的 实现 支持 标准 的 API， 可 以 预期 的 
是 ， 仅 当 使 用 java.sql.PreparedStatement 接 口 重 复 执 行 拥 有 不 同 绑 定 变量 的 同一 条 SQL 语句 
时 才 会 有 性 能 提升 。 


4. ODP.NET 

要 通过 ODPNET 使 用 数组 接口 ， 基 于 数组 定义 参数 ， 并 将 存储 在 数组 中 值 的 数量 设置 为 
ArrayBindCount 属 性 的 值 就 可 以 了 。 下 面 的 代码 片段 ， 通 过 在 单独 的 一 次 执行 中 插入 100 000 行 数据 ， 
证 实 了 这 一 点 。 可 以 在 ArrayInterface.cs 文 件 中 的 C# 程 序 中 找到 完整 的 例子 : 


new Decimal[100000]; 
new String[100000]; 


Decimal[] idValues 
String[] padvalues 


for (int i=0 ; ic100000 ; i++) 


idvalues[i] = i; 
padValues[i] = "... some text ..."; 


id = new OracleParameter(); 
id.0racleDbType = OracleDbType.Decimal; 
id.Value = idValues; 
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pad = new OracleParameter(); 
pad.OracleDbType = OracleDbType.Varchar2; 
pad.Value = padValues,; 


sql = "INSERT INTO t VALUES (:id, :pad)"; 
command = new OracleCommand(sql, connection); 
command.ArrayBindCount = idValues.Length; 
command.Parameters.Add(id); 
command.Parameters.Add(pad); 

command. ExecuteNonQuery(); 


15.6.2 ” 何 时 使 用 


无 论 何 时 需要 持 入 或 修改 超过 一 行 的 数据 时 ,使 用 数组 接口 就 是 合理 的 。 你 只 需要 考虑 在 客户 端 
可 能 会 因为 存储 数组 而 需要 更 多 的 内 存 。 通 常 ， 这 都 不 会 成 为 问题 ， 除 非 使 用 的 数组 大 小 很 夸张 。 


15.6.3 ”陷阱 和 诺 误 


在 通过 SQL 跟踪 生成 的 执行 统计 中 , 没有 明显 的 关于 使 用 数组 处 理 的 信息 。 但 是 , 如 果 你 知道 SQL 
语句 是 哪 一 个 ， 通 过 查看 修改 的 行 数 和 执行 的 次 数 之 间 的 比率 ， 应 该 能 够 确定 是 否 使 用 了 数组 处 理 。 
举例 来 说 ， 在 下 面 的 执行 统计 中 ， 一 个 普通 的 INSERT 语 句 ， 只 被 执行 了 一 次 ， 插 入 了 2342 行 数据 。 这 
样 的 结果 可 能 只 会 在 使 用 数组 接口 时 才 会 出 现 : 

INSERT INTO T VALUES (:B1 ，:B2 ) 


call count cpu elapsed disk query current TOWS 
Parse 1 0.00 0.00 0 0 0 0 
Execute 1 0.00 0.00 0 78 522 2342 
Fetch 0 0.00 0.00 0 0 0 0 
total 2 0.00 0.00 0 78 522 2342 


15.7 ”小结 


本 章 描 述 了 几 种 致力 于 改进 性 能 的 高 级 优化 技术 。 其 中 的 一 些 优化 技术 ( 物化 视图 、 结 果 缓 存 、 
并 行 处 理 和 直接 路 径 插 入 )， 只 应 该 在 “正常 ”的 优化 技术 无 法 实现 要 求 的 性 能 时 才 去 使 用 。 比 较 起 
来 ， 其 他 的 优化 技术 ( 行 预 取 和 数组 处 理 ) 则 应 该 尽 可 能 多 地 使 用 。 

尽管 本 章 主要 描述 那些 并 不 常用 的 优化 技术 , 但 是 接 下 来 ( 最 后 ) 的 一 章 涵盖 的 优化 技术 ， 基 本 
上 适用 于 在 数据 库 中 存储 的 每 一 张 表 。 事 实 上 ， 当 你 执行 从 逻辑 设计 到 物理 设计 的 转变 的 时 候 ， 有 必 
要 确定 每 一 张 表 在 物理 上 是 如 何 存 储 数据 的 。 


优化 物理 设计 ， 


在 从 你 辑 设计 向 物理 设计 的 转换 过 程 中 ， 必 须 做 出 四 种 类 型 的 决策 。 第 一 ， 对 于 每 一 张 表 ， 不仅 
要 决定 是 否 应 该 使 用 堆 表 、 群 集 或 者 索引 组 织 表 ， 而 且 还 要 决定 是 否 需要 使 用 分 区 。 第 二 ， 必 须 考虑 
是 否 应 该 利用 诸如 索引 或 物化 视图 等 元 余 访问 结构 。 第 三 ， 必 须 决定 如 何 实现 约束 (这 里 不 是 讨论 你 
是 否 必须 实现 它们 )。 第 四 ， 必 须 决 定数 据 如 何在 块 中 存储 ， 包 括 列 的 顺序 ， 使 用 什么 样 的 数据 类 型 ， 
每 个 块 中 应 该 存储 多 少 行 数 据 ， 或 者 是 否 应 该 激活 压缩 功能 。 本 章 只 关注 第 四 个 主题 。 关 于 其 他 三 个 
主题 的 信息 ， 尤 其 是 前 两 个 ， 请 参考 第 13 草 、 第 14 章 和 第 15 章 。 

本 章 的 目标 是 解释 为 何不 应 该 将 物理 设计 的 优化 视 为 微调 的 活动 ， 而 是 作为 一 项 基本 的 优化 技 
术 。 本 章 的 起 点 是 讨论 为 何 选择 正确 的 列 顺序 和 正确 的 数据 类 型 事 关 重大 。 接 下 来 会 解释 什么 是 行 迁 
移 和 行 链接 ， 如 何 定位 与 它们 有 关 的 问题 ， 以 及 如 何 从 一 开始 就 避免 行 迁移 和 行 链接 。 然 后 ， 本 章 会 
描述 拥有 高 负载 的 系统 会 经 历 的 一 个 常见 性 能 问题 : 块 争 用 。 最 后 ， 本 章 还 会 描述 如 何 利用 数据 压缩 
来 改进 性 能 。 


16.1 最 优 列 顺序 


我 们 通常 很 少 会 将 注意 力 放 在 如 何 为 一 张 表 找 出 最 优 列 顺序 上 面 。 根据 有 具体 情况 ， 列 顺序 既 可 能 
没有 丝毫 影响 ， 也 可 能 会 引发 显著 的 开销 。 要 理解 什么 情况 下 可 能 会 引发 显著 的 开销 ， 就 十 分 有 必要 
讲述 一 下 数据 库 引 擎 是 如 何在 块 中 存储 数据 的 ， 

在 块 中 存储 一 行 数据 有 着 非常 简单 的 格式 ( 见 图 16-1 ) 首先， 有 一 个 头 部 (H ) 记录 着 关于 数据 
行 本身 的 一 些 属性 ， 比 如 它 是 否 被 锁定 或 它 包含 了 多 少 个 列 。 然 后 ， 是 各 个 列 。 因 为 每 个 列 都 可 能 拥 
有 不 同 的 大 小 ， 所 以 它们 中 的 每 一 个 都 由 两 部 分 组 成 。 第 一 部 分 是 数据 的 长 度 (Ln )。 第 二 部 分 是 数 
据 本 身 (Dn )。 


Tm lm] 
图 16-1 数据 块 中 存储 的 数据 行 的 格式 (H= 行 的 头 部 ，Ln = 第 n 列 的 长 度 ， 
Dn= 第 n 列 的 数据 ) 
在 这 个 格式 中 要 理解 的 重点 是 数据 库 引 擎 不 知道 一 行 数据 中 各 个 列 的 偏 移 量 。 举 例 来 说 ， 如 果 它 
必须 要 定位 列 3， 那 么 它 不 得 不 从 定位 列 1 开 始 ( 这 个 简单 ， 因 为 头 部 的 长 度 是 已 知 的 )， 然 后 ， 根 据 
列 1 的 长 度 , 它 定 位 到 列 2。 最 后 ,根据 列 2 的 长 度 , 它 定位 到 列 3。 所 以 无 论 何 时 当 行 里 面包 含 很 多 列 ， 
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那么 定位 接近 开头 位 置 的 列 要 比 定位 接近 行 未 尾 的 列 要 快 得 多 。 为 了 更 好 地 理解 此 内 容 ， 可 以 执行 下 
面 的 测试 ， 该 测试 来 自 column_order.sql 脚 本 ， 用 来 测量 与 列 的 搜索 有 关 的 开销 。 

(1) 创建 一 张 拥有 250 个 列 的 表 : 

CREATE TABLE t (n1 NUMBER, n2 NUMBER，...，n249 NUMBER, n250 NUMBER) 

(2) 插入 10 000 条 数据 。 每 一 行 的 每 一 列 都 存储 相同 的 值 。 

(3) 为 下 面 的 查询 测量 响应 时 间 ， 为 每 个 列 循环 执行 1000 次 : 

SELECT count(<col>) FROM 七 

图 16-2 总 结 了 这 个 测试 在 我 的 测试 服务 器 上 运行 的 结果 。 需 要 注意 的 是 ， 引 用 第 一 个 列 〈 位置 1 ) 
的 查询 执行 速度 是 引用 第 250 个 列 〈 位 置 250 ) 的 查询 的 五 倍 。 这 是 因为 数据 库 引擎 优化 了 每 次 访问 ， 
而 且 因此 避免 了 多 余 的 列 定位 和 读 取 的 处 理工 作 。 举 例 来 说 ，SELECT count(n3) FROM t 这 个 查询 在 定 
位 到 第 三 个 列 以 后 , 就 停止 了 后 续 检 索 数据 行 的 操作 - 图 16-2 同 样 报告 了 , 在 位 置 0, count(*) 的 计算 ， 
根本 不 需要 访问 任何 列 。 


响应 时 间 ( 秒 ) 
~ 


0 25 50 75 100 125 150 175 200 225 250 
列 位 置 
图 16-2 一 个 列 在 数据 行 中 的 位 置 与 访问 它 需 要 的 处 理 总 量 


因为 如 此 ,惯用 规则 是 首先 放置 需要 经 常 访问 的 列 。 然 而 ,为 了 利用 这 种 特性 ， 你 应 该 要 注意 只 
访问 那些 真正 需要 的 列 。 无 论 如 何 ， 从 性 能 的 角度 来 看 ， 查 询 不 需要 的 列 ( 或 更 糟糕 的 情况 是 ,经 常 
使 用 SELECT * 引 用 所 有 的 列 ， 即 使 是 只 有 一 部 分 列 是 应 用 程序 需要 的 ) 都 是 不 好 的 ， 不仅 因为 从 数据 
块 中 读 取 它们 时 存在 着 开销 ,而 且 就 像 你 刚刚 看 到 的 那样 ,也 是 因为 在 服务 器 以 及 客户 端 上 临时 存储 
它们 时 需要 更 多 的 内 存 , 而 且 在 网 络 上 发 送 它 们 也 需要 更 多 的 时 间 和 资源 , 简 而 言 之 , 每 次 处 理 数据 ， 
都 会 有 开销 。 

在 实践 中 ， 与 列 的 位 置 有 关 的 开销 在 下 列 的 情形 当中 是 ( 更 加 ) 显著 的 。 

口 当 表 拥有 许多 列 ， 而 且 SQL 语 句 经 常 引 用 存储 于 行 末 的 列 的 很 少 一 部 分 时 

口 当 从 一 个 块 中 读 取 很 多 行 时 ， 比 如 在 全 表 扫 描 期 间 。 这 是 因为 ,通常 访 问 每 个 块 中 的 少数 行 

时 ， 定 位 和 访问 一 个 块 的 开销 远 远 高 于 仅 读 取 少 数 行 时 定位 和 访问 列 的 开销 。 举 例 来 说 ， 如 
果 通 过 将 PCTFREE 设 置 为 90 ( 因此 我 降低 了 每 个 块 中 的 记录 数 ) 来 运行 column_order.sql 肢 本 ， 
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引用 第 一 个 列 的 查询 执行 速度 只 比 引用 第 250 列 的 查询 快 不 到 两 倍 ( 如 在 图 16-2 中 看 到 的 ， 与 
将 PCTFREE 设 置 为 10 时 相 比 ， 快 了 大 约 五 倍 )。 
因为 尾部 的 NULL 值 不 存储 ， 所 以 将 预期 会 包含 NULL 值 的 列 放置 在 表 的 未 尾 显得 比较 合理 。 通 过 这 
种 方式 ， 物 理 存 储 的 列 数量 以 及 关联 的 平均 行 大 小 都 有 可 能 随 之 降低 


16.2 最 优 数 据 类 型 


最 近 这 些 年 我 见证 了 在 物理 设计 方面 的 一 个 令 人 担忧 的 趋势 ， 我 称 之 为 错误 的 数据 类 型 选择 
(wrong datatype selection )， 我 在 1.2 节 中 简单 介绍 过 这 一 趋势 . 乍 看 之 下 ， 为 一 个 列 选择 数据 类 型 看 起 
来 像 是 要 做 出 的 一 个 非常 直截了当 的 决定 。 然 而 , 在 这 样 的 一 个 世界 里 ,软件 模 式 师 通常 会 花费 大 量 
的 时 间 来 讨论 诸如 敏捷 软件 开发 、SOA 或 持久 层 框架 这 样 高 层次 的 事情 ， 大 多 数 人 看 起 来 是 忘记 了 低 
层次 的 事情 。 我 相信 十 分 有 必要 回归 底层 基础 ， 并 讨论 为 什么 数据 类 型 选择 如 此 重要 


16.2.1 数据 类 型 选择 中 的 陷阱 


为 了 演示 数据 类 型 选择 中 的 错误 ， 接 下 来 我 会 展现 曾经 反复 遇 到 过 的 五 个 典型 问题 的 例子 

第 一 个 由 数据 类 型 选择 错误 引起 的 问题 ， 是 在 数据 库 中 插入 或 修改 数据 时 使 用 了 错误 的 数据 验 
证 ， 或 缺少 数据 验证 。 举 例 来 说 ， 如 果 一 个 列 本 来 应 该 存储 数字 值 ， 实 际 为 它 选择 一 个 字符 串 数 据 
类 型 ， 那 么 就 需要 一 个 外 部 校 验 。 换 句 话 说， 数据 库 引 擎 无 法 校 验 数 据 。 数 据 库 引擎 将 这 个 工作 留 
给 应 用 程序 去 做 。 即 使 这 样 的 一 个 验证 很 容易 实现 ， 也 要 牢记 相 比较 集 中 在 数据 库 而 言 ， 每 次 当 这 
段 相同 的 代码 被 分 发 到 多 个 位 置 时 ， 早 晚会 出 现 功能 上 不 一 致 的 情况 ( 典型 的 例子 ， 在 某 些 位 置 上 
的 校 验 可 能 被 忘记 了 ， 或 可 能 后 来 校 验 规则 发 生 所 改变 ， 而 实现 规则 的 程序 只 在 一 部 分 位 置 上 进行 
了 更 新 )。 我 即将 呈现 的 例子 与 nls_numeric_ characters 初 始 化 参数 有 关 。 记 住 这 个 初始 化 参数 指定 
的 是 小 数 和 数值 分 隔 符 使 用 的 特性 。 例 如 ， 在 瑞士 它 经常 被 设置 为 “.,”"， 因 此 的 值 被 格式 化 成 这 
样 : 3.14159。 相 反 , 在 德国 它 通常 被 设置 为 “,.”, 因此 同样 的 一 个 值 会 被 格式 化 为 : 3,14159。 迟 早 ， 
因为 在 数据 库 中 使 用 了 错误 的 数据 类 型 ， 对 该 初始 化 参数 使 用 了 不 同 的 客户 端 设置 的 应 用 程序 ， 如 
果 执 行 从 VARCHAR2 回 NUMBER 类 型 的 转换 ， 将 会 引发 一 个 ORA-01722:invalid number 错 误 。 而 且 等 到 你 
注意 到 这 个 问题 的 时 候 , 你 的 数据 库 将 会 被 包含 两 种 格式 的 VARCHAR2 列 填 满 , 而 且 那 时 候 就 会 震 要 执 
行 令 人 头疼 的 数据 校正 。 

第 二 个 由 数据 类 型 选择 错误 引起 的 问题 是 信息 的 丢失 。 换 名 话说 ,在 从 原始 的 (正确 的 ) 数据 类 
型 问 数 据 库 的 数据 类 型 转换 期 间 ， 信 息 会 发 生 丢 失 。 举例 来 说 ,想象 一 下 当 使 用 DATE 数 据 类 型 存储 一 
个 事件 的 日 期 和 时 间 ， 而 不 是 使 用 TIMESTAMP WITH TIME ZONE 数据 类 型 时 会 发 生 什 么 。 小 数 部 分 的 秘 
和 时 区 信息 会 丢失 。 尽 管 小 数 部 分 的 秒 导致 的 问题 可 能 会 被 认为 是 小 错误 (不 到 1 秒 钟 )， 而 时 区 则 可 
能 是 一 个 更 大 的 问题 。 在 我 曾经 亲身 经 历 的 一 个 案例 中 , 一 个 客户 的 数据 总 是 使 用 本 地 标准 时 间 ( 没 
有 夏令 时 调整 ) 生成 , 并 直接 存储 在 数据 库 中 。 当 出 于 报表 的 原因 而 必须 应 用 一 个 夏令 时 修正 的 时 候 ， 
问题 就 发 生 了 。 一 个 设计 用 于 在 两 个 时 区 之 间 进 行 转换 的 函数 被 实现 出 来 。 它 的 使 用 方法 如 下 : 

new time dst(in date DATE, tz1 VARCHAR2, tz2 VARCHAR2) RETURN DATE 

调用 一 个 这 样 的 函数 非常 快速 。 问 题 是 在 每 个 报表 中 都 会 成 千 上 万 次 调用 它 。 结 果 响 应 时 间 增 加 
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了 25 倍 。 很 明显 , 使 用 正确 的 数据 类 型 , 所 有 的 事情 不 仅 会 更 快 , 而 且 会 更 容易 ( 转换 会 被 自动 执行 )。 

第 三 个 由 数据 类 型 选择 错误 引起 的 问题 是 事情 不 像 期 望 的 那样 运转 。 比 如 说 你 必须 对 一 张 表 进行 
范围 分 区 ， 基 于 一 个 存储 着 日 期 和 时 间 信 息 的 DATE 或 TIMESTAMP 列 。 这 通常 没什么 大 不 了 的 。 如 果 分 区 
键 使 用 的 列 包 含 基 于 某 种 格式 掩 码 的 日 期 时 间 值 的 数字 表现 形式 ， 或 等 价 的 字符 串 表 现形 式 ， 代 替 了 
原本 的 DATE 或 TIMESTAMP 值 ， 此 时 就 会 发 生 问题 。 如 果 从 日 期 时 间 值 向 数字 值 的 转换 是 通过 类 似 
YYYYMMDDHH24MISS 的 格式 掩 码 执行 的 ， 范 围 分 区 的 定义 仍然 是 有 可 能 的 。 然 而 ， 如 果 转 换 是 基于 类 似 
DDMMYYYYHH24MISS 这 样 的 格式 掩 码 ， 因 为 数字 ( 或 字符 串 ) 顺序 并 非 按 自然 的 日 期 时 间 值 顺序 保存 的 ， 
在 不 变更 列 的 数据 类 型 或 格式 的 情况 下 你 根本 没有 机 会 解决 这 个 问题 ( 自 11.1 版 本 开始 ， 在 某 些 情况 
下 有 可 能 通过 实现 基于 虚拟 列 的 分 区 解决 这 个 问题 )。 

第 四 个 由 数据 类 型 选择 错误 引起 的 问题 与 查询 优化 器 有 关 -。 这 可 能 是 这 个 候选 名 单 上 最 不 明显 的 
一 个 ,也 是 导致 问题 时 最 微妙 的 一 个 。 这 个 问题 的 原因 是 使 用 错误 的 数据 类 型 ， 查 询 优化 器 会 执行 错 
误 的 估算 ， 因 此 ,选择 的 访问 路 径 不 是 最 优 的 。 通常， 像 这 样 的 事情 发 生 的 时 候 ， 大 多 数 人 会 责怪 查 
询 优 化 器 “又 一 次 ”没有 做 好 本 职工 作 。 实 际 上 ， 问题 是 你 向 查询 优化 器 隐藏 了 信息 ， 所 以 它 无 法 正 
确 地 完成 它 的 工作 。 为 了 更 好 地 理解 这 个 问题 ， 看 一 下 下 面 的 例子 ， 它 来 自 wrong_datatype.sql 这 个 
脚本 。 在 这 里 ， 你 会 看 到 对 于 类 似 的 限制 条 件 ， 三 个 存储 相同 数据 集 ( 2014 年 的 每 一 天 的 日 期 ) 但 是 
使 用 不 同 数据 类 型 的 列 ， 估 算出 来 的 基数 之 间 的 不 同 。 正 如 你 所 见 到 的 ,查询 优化 器 只 能 够 为 正确 定 
义 的 列 做 出 合理 的 估算 ( 正确 的 基数 是 28 );，  ” 

SQL> CREATE TABLE t (d DATE, n NUMBER(8)，c VARCHAR2(8)); 

SQL> INSERT INTO t (d) 

2 SELECT to date('20140101','YYYYMMDD' )+level-1 


3 FROM dual 
4 CONNECT BY level <= 365; 


SOL> UPDATE t SET n = to number(to char(d,'YYYYMMDD')), ¢ = to char(d,'YYYYMMDD' ); 
SQL> execute dbms stats.gather table stats(ownname=>user, tabname=>'t') 


SQL> SELECT * FROM t ORDER BY d; 


01-JAN-14 20140101 20140101 
02-JAN-14 20140102 20140102 


30-DEC-14 20141230 20141230 
31-DEC-14 20141231 20141231 


SOL> EXPLAIN PLAN SET STATEMENT ID = 'd' FOR 
人 ELECT * 
3 FROM t 
4 WHERE d BETWEEN to date('20140201','YYYYMMDD') AND to date('20140228",'YYYYMMDD' ) ; 


SQL> EXPLAIN PLAN SET STATEMENT ID = “n” FOR 
SELECT 党 
3 FROM + 
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4 WHERE n BETWEEN 20140201 AND 20140228; 


SQL> EXPLAIN PLAN SET STATEMENT ID = '¢' FOR 
2 SELECT * 
3 FROM 七 
4 WHERE C BETWEEN '20140201' AND “20140228  ; 


SQL> SELECT statement id, cardinality FROM plan table WHERE id = 0; 


STATEMENT_ID CARDINALITY 


d 29 
n 11 
姑 11 


第 五 个 问题 同样 与 查询 优化 器 有 关 。 但 是 这 一 次 ， 是 因为 隐 式 转换 ( 作为 一 个 通用 规则 ， 始 终 应 
该 避免 隐 式 转换 )。 可 能 发 生 隐 式 转换 阻止 查询 优化 器 选择 索引 的 问题 。 为 了 演示 这 个 问题 ， 我 使 用 
前 面 例子 中 的 同一 张 表 。 在 这 张 表 上 ， 会 创建 出 一 个 基于 VARCHAR2 数 据 类 型 的 列 的 索引 。 如 果 WHERE 
子 句 包含 对 使 用 字符 串 的 列 的 限制 , 查询 优化 器 会 选择 该 索引 。 然而 , 如 果 限 制 条 件 上 使 用 了 数字 ( 开 
发 人 员 自 己 “ 知 道 ” 只 有 数字 值 存储 在 列 中 …… )， 则 会 使 用 全 表 扫 描 ( 注意， 在 第 二 个 SQL 语句 中 ， 
基于 to_number 函 数 的 隐 式 转换 阻止 了 该 索引 的 使 用 )， 因 此 查询 优化 器 就 正常 地 忽略 了 该 索引 。 

SOL> CREATE INDEX i ON t (c); 


SQL> SELECT /*+ index(t) */ * 
2 FROM 七 
3 WHERE c = '20140228'; 


| Id | Operation | Name | 


0 | SELECT STATEMENT | 
1 | TABLE ACCESS BY INDEX ROWID| T | 
2 | INDEX RANGE SCAN 1 渗 .， Il 


2 - access("C"="'20140228') 


SQL> SELECT /*+ index(t) */ * 
2 FROM 七 
3 WHERE cC = 20140228; 


| Id | Operation | Name | 


| 0 | SELECT STATEMENT | | 
|* 4 | TABLE ACCESS FULLIT | 


1 - filter(TO NUMBER("C")=20140228) 


概括 起 来 ， 你 有 充足 的 理由 去 选择 正确 的 数据 类 型 。 这 样 做 可 能 会 为 你 省 去 一 大 堆 问 题 。 
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16.2.2 ”数据 类 型 选择 最 佳 实践 


正如 上 一 节 中 讨论 的 那样 ， 核 心 原则 是 每 种 数据 类 型 都 应 该 只 存储 它们 被 设计 用 来 存储 的 值 。 举 
个 例子 ,数字 必须 存储 在 数字 数据 类 型 中 ， 而 不 是 字符 串 数据 类 型 中 。 此 外 ,一 旦 存在 多 种 数据 类 型 
(例如 ， 几 种 数据 类 型 都 可 以 存储 字符 串 ) 可 选 时 ， 最 重要 的 原则 就 是 所 选择 的 数据 类 型 ， 能 够 以 最 
高 效 的 方式 完整 地 存储 数据 。 换 句 话 说， 应 该 避免 丢失 信息 或 性 能 。 

接 下 来 的 部 分 会 提供 一 些 选择 数据 类 型 时 应 该 考虑 的 信息 ( 主要 与 性 能 有 关 )。 这 些 部 分 涵盖 四 
个 主要 的 内 置 数据 类 型 类 别 : 数字 、 字 符 串 、 比 特 串 以 及 日 期 时 间 。 


1. 数字 

用 来 存储 浮 点 型 数值 和 整 型 数值 的 主要 数据 类 型 是 NUMBER。 这 是 一 种 可 变 长 的 数据 类 型 。 这 意味 
着 可 以 通过 精度 和 小 数 范围 来 指定 用 于 存储 数据 的 精确 度 。 一 旦 这 种 数据 类 型 用 于 存储 整数 ， 或 一 
旦 完整 的 精确 度 没有 必要 ,一定 要 记得 指定 范围 以 节省 空间 。 下 面 的 例子 展示 相同 的 输入 值 ， 根 据 不 
同 的 小 数 范围 ， 是 如 何 被 舍 人 为 21 个 字 节 或 2 个 字 节 的 : 

SOL> CREATE TABLE t (n1 NUMBER, n2 NUMBER(*,2)); 

SOL> INSERT INTO t VALUES (1/3, 1/3); 


SQL> SELECT * FROM t; 


.3333333333333333333333333333333333333333 .33 
SOL> SELECT vsize(n1), vsize(n2) FROM 七 ; 


VSIZE(N1) VSIZE(N2) 


因为 内 部 格式 是 专 有 的 , CPU 无 法 使 用 硬件 浮 点 单元 直接 处 理 以 NUMBER 类 型 存储 的 值 。 取而代之 ， 
CPU 通过 内 部 的 Oracle 库 程序 来 处 理 这 些 浮 点 值 。 因 为 这 个 原因 ， 在 支撑 数值 计算 负载 时 NUMBER 数 据 
类 型 不 够 高 效 。 为 解决 这 个 问题 ， 可 以 使 用 BINARY_FLOAT 和 BINARY_DOUBLE。 与 NUMBER 数 据 类 型 相 比 ， 
它们 的 核心 优势 是 它们 实现 了 IEEE 754 标 准 ， 因 此 CPU 可 以 直接 处 理 它们 。 这 两 种 类 型 的 主要 劣势 是 
它们 是 基于 二 进 制 的 浮 点 数 。 因 此 ,这些 类 型 无 法 精确 地 表示 经 常用 于 商业 和 财务 应 用 程序 的 十 进 制 
小 数 。 表 16-1 总 结 了 这 三 种 数据 类 型 之 间 的 关键 不 同 点 。 


表 16-1 数字 数据 类 型 比较 


属 性 NUMBER (精度 ， 小 数 范围 ) BINARY_FLOAT BINARY_DOUBLE 
取 值 范围 +1.0E126 土 3.40E38 + 1.79E308 
长 度 1~22 字 节 4 字 节 8 字 节 
支持 正 负 无 穷 大 是 是 是 
支持 NAN 中 是 是 
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( 续 ) 
属 性 NUMBER (精度 ， 小 数 范围 ) BINARY_FLOAT BINARY_DOUBLE 
优势 精确 性 速度 速度 
可 以 指定 精度 和 小 数 范围 固定 长 度 固定 长 度 
2. 字符 串 


有 三 种 基本 的 数据 类 型 用 于 存储 字符 串 : VARCHAR2 、CHAR 和 CLOB。 前 两 种 最 高 分 别 支持 4000 和 2000 
个 字 节 ( 注意 最 大 长 度 是 按 字 节 指定 的 ， 不 是 字符 )。 第 三 种 最 高 支持 几 TB 的 数据 ( 实际 值 取决 于 默 
认 的 块 大 小 )。VARCHAR2 与 CHAR 之 间 最 大 的 不 同 是 前 者 为 可 变 长 类 型 ， 而 后 者 是 固定 长 度 的 。 这 意味 着 
CHAR 通 常用 于 字符 串 长 度 已 知 的 情况 下 。 但 是 ,我 的 建议 是 全 部 使 用 VARCHAR2 ， 因 为 它 提供 比 CHAR 类 
型 更 好 的 性 能 。 只 有 在 预期 字符 串 的 长 度 要 比 VARCHAR2 支 持 的 最 大 长 度 还 要 大 的 时 候 ， 才 使 用 CLOB 类 
型 。 从 11.1 版 本 开始 ，CcLoB 的 存储 方法 有 两 种 : basicfile 和 securefile。 出 于 性 能 的 考虑 ， 应 该 使 用 
securefile, 

当 使 用 VARCHAR2 和 CHAR 数 据 类 型 时 ， 不 应 该 将 其 最 大 长 度 设置 为 没有 必要 的 长 度 。 这 是 因为 在 某 
些 情况 下 ， 即 使 可 能 没有 用 到 全 部 空间 ,数据库 引 擎 也 会 不 得 不 分 配 足够 的 内 存 来 存储 你 指定 的 最 大 
长 度 。 see 可 能 会 有 大 量 的 内 存 被 分 配 却 完全 用 不 到 。 

三 种 基本 的 数据 类 型 按照 数据 库 字符 集 存 储 字符 串 。 此 外 ， 其 他 的 三 种 数据 类 型 ，NVARCHAR2 、 
Sr rat ee me 
这 三 种 数据 类 型 和 对 应 的 同名 基本 类 型 有 着 相同 特征 。 只 有 它们 的 字符 集 不 同 。 

LONG 是 另 一 种 字符 串 数据 类 型 ， 为 支持 cL08 忆 经 不 扒 着 人 用 T， 你 不 应 该 再 使 用 它 ; 提供 这 种 类 
型 仅 是 出 于 向 后 兼容 性 的 考虑 。 


警告 ”从 12.1 版 本 开始 ， 可 以 将 max_string size 初 始 化 参数 的 值 设置 为 extended， 以 便 将 VARCHAR2、 
NVARCHAR2 和 RAW 类 型 的 最 大 长 度 增加 至 32 767 字 节 。 这样 做 的 缺点 是 数据 库 引 擎 会 静默 地 采用 
LOB 数 据 类 型 来 支持 这 种 更 大 的 最 大 长 度 。 我 的 建议 是 保持 max_string_size 初 始 化 参数 的 值 
为 默认 设置 ( standard )， 如 果 需 要 更 大 的 空间 ， 请 显 式 使 用 LOB 数 据 类 型 。 


3. 比特 串 
有 两 种 数据 类 型 用 于 存储 比特 串 : RAW 和 BL0B。 第 一 种 最 高 支持 2000 个 字 节 。 只 有 在 预计 比特 串 大 
于 2000 个 字 节 时 ， 才 应 该 使 用 第 二 种 类 型 。 从 11.1 版 本 开始 ，BLoB 的 存储 方法 有 两 种 : basicfile 和 
人 出 于 性 能 的 考虑 ， 应 该 使 用 securefile。 
一 种 比特 串 数据 类 型 是 LONG RANW， 但 是 为 了 支持 BLOB 已 经 不 推荐 使 用 。 你 不 应 该 再 使 用 它 ; 提 
eh tt 


4. 日 期 时 间 
用 于 存储 日 期 时 间 值 的 数据 类 型 有 DATE、TIMESTAMP 、TIMESTAMP WITH TIME ZONE 以 及 TIMESTAMP NITH 
LOCAL TIME ZONE。 这 几 种 类 型 都 会 存储 的 信息 如 下 : 年 、 月 、 日 、 小 时 、 分 钟 以 及 秒 。 这 部 分 的 长 度 
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国定 在 7 个 字 节 。 三 种 基于 TIMESTAMP 的 数据 类 型 可 能 还 会 存储 秒 的 小 数 部 分 ( 0-~9 位 数字 ， 默 认 6 位 )。 
这 部 分 是 可 变 长 度 : 0~4 字 节 。 最 后 ，TIMESTAMP WITH TIME ZONE 使 用 两 个 额外 的 字 节 存储 时 区 。 因 为 
它们 全 部 都 存储 不 同 的 信息 ， 存 储 所 需 数据 占用 空间 最 少 的 那 一 种 ， 就 是 最 合适 的 数据 类 型 。 


16.3 ” 行 迁 移 和 行 链接 
迁移 和 链接 的 行经 常 被 搞 混 。 依 我 看 来 ， 主 要 的 原因 有 两 个 。 第 一 ， 两 者 有 共同 的 特性 ， 所 
以 很 容易 混淆 。 第 二 ，Oracle 在 它 的 文档 以 及 软件 实现 当中 ， 在 如 何 区 分 两 者 这 一 点 上 从 来 没有 


非常 一 臻 过。 所 以 ， 在 描述 如 何 发 现 和 避免 行 迁移 和 行 链接 之 前 ， 很 有 必要 简单 描述 一 下 两 者 之 
间 的 区 别 。 


16.3.1 迁移 与 链接 


将 记录 插入 到 一 个 块 中 时 ， 数 据 库 引擎 会 保留 一 些 空闲 空间 以 供 未 来 更 新 使 用 。 可 以 通过 使 用 
PCTFREE 参 数 来 定义 为 更 新 保留 的 空闲 空间 总 量 。 为 了 演示 这 个 参数 , 我 在 图 16-3 描 绘 的 块 中 插入 了 六 
行 数据 。 因 为 达到 了 通过 PCTFREE 设 置 的 国 值 ， 对 于 这 个 块 来 讲 不 再 能 够 插入 数据 。 


图 16-3 ”插入 时 会 留 出 一 些 空闲 空间 供 未 来 更 新 


更 新 一 行 记 录 并 且 其 长 度 增加 时 ,数据 库 引擎 会 尝试 在 存储 它 的 块 中 寻找 足够 的 空闲 空间 。 当 没 
有 足够 的 空闲 空间 可 用 时 ,会 将 此 行 数据 分 为 两 个 片断 。 第 一 个 片断 ( 只 包含 控制 信息 ， 比 如 指向 第 
二 个 片断 的 rowid ) 保留 在 原始 的 块 中 。 这 对 于 避免 变更 rowid 来 说 是 有 必要 的 。 理 解 这 一 点 至 关 重 要 ， 
因为 rowid 不 仅 会 被 数据 库 引 警 永久 地 存储 在 索引 中 ， 而 且 也 会 被 客户 端 应 用 程序 临时 存储 在 内 存 中 。 
第 二 个 片断 ， 包 含 所 有 的 数据 ， 进 入 到 男 一 个 块 当中 。 这 种 类 型 的 行 称 为 迁移 的 行 。 例 如 ， 在 图 16-4 
中 ， 行 4 就 被 迁移 了 。 
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图 16-4 更 新 后 的 行 因为 无 法 继续 存储 在 原始 的 块 中 而 被 迁移 至 另 一 个 块 中 
当 一 行 数据 太 大 而 无 法 放 人 到 一 个 单独 的 块 中 ， 它 就 会 被 分 为 两 个 或 更 多 的 片断 。 然 后 ， 每 个 片 
断 都 被 存储 在 一 个 不 同 的 块 中 ， 此 时 在 各 个 片断 之 间 就 会 建立 起 一 个 链接 。 这 种 类 型 的 行 称 为 链接 的 
行 。 为 了 演示 ， 图 16-5 展 示 了 一 个 链接 了 三 个 块 的 行 。 


图 16-5 一 个 链接 的 行 被 分 为 两 个 或 更 多 的 部 分 


还 有 另外 一 种 情况 会 引起 行 链接 : 拥有 超过 255 个 列 的 表 。 实 际 上 ， 数 据 库 引 擎 无 法 在 一 个 单独 
的 行 片断 中 存储 超过 255 个 列 。 因 此 ， 一 且 需 要 存储 的 列 超过 255 个 时 ， 这 个 行 就 会 分 裂 成 几 个 片断 。 
这 是 一 种 特殊 情况 ， 这 几 个 属于 同一 行 的 片断 也 可 以 存储 在 一 个 单独 的 块 中 。 这 称 为 块 内 行 链接 。 图 
16-6 展 示 了 一 个 拥有 三 个 片断 ( 因为 它 有 654 个 列 ) 的 行 。 

注意 , 迁移 的 行 是 由 更 新 引起 , 而 链接 的 行 是 由 插入 或 者 更 新 引起 。 当 链接 的 行 是 由 更 新 引起 时 ， 
迁移 和 链接 可 能 会 同时 发 生 在 这 些 行 上 。 


16.3 ” 行 迁移 和 行 链接 593 


图 16-6 ”拥有 超过 255 列 的 表 可 能 会 引起 块 内 行 链接 


16.3.2 ”问题 描述 


由 行 迁移 引起 的 性 能 影响 取决 于 读 取 行 所 使 用 的 访问 路 径 。 如 果 迁 移 的 行 是 通过 rowid 进 行 访问 
的 ， 则 成 本 加 倍 。 事 实 上 ， 需 要 分 别 访问 两 个 行 片断 。 相 反 ， 如 果 它 们 是 通过 全 表 扫描 进行 访问 的 ， 
则 没有 什么 开销 。 这 是 因为 第 一 个 行 片断 不 包含 数据 ， 会 被 直接 跳 过 。 

由 行 链接 引起 的 性 能 影响 与 访问 路 径 无 关 。 事 实 上 ,每 次 找到 第 一 个 行 片断 时 ,都 有 必要 通过 rowid 
访问 其 他 所 有 的 片断 。 但 是 ， 有 一 个 例外 情况 。 正 如 之 前 在 16.1 节 中 讨论 过 的 ， 当 只 需要 行 的 一 部 分 
时 ， 可 能 不 需要 访问 所 有 的 片断 。 举 例 来 说 ， 如 果 只 需要 在 第 一 个 片断 中 存储 的 列 ， 则 没有 必要 访问 
其 他 所 有 的 片断 。 

与 行 迁移 、 行 链接 两 者 都 有 关联 的 开销 与 行 级 锁 有 关系 。 必 须 锁定 每 一 个 行 片断 。 这 意味 着 由 锁 
定 引起 的 开销 会 随 片 断 的 数量 成 比例 增加 。 


16.3.3 ”问题 识别 


主要 有 两 种 方法 用 于 检测 迁移 和 链接 的 行 。 遗 憾 的 是 ， 两 者 都 不 是 基于 响应 时 间 的 。 这 意味 着 没 
有 关于 该 问题 带 来 的 真正 影响 的 信息 。 第 一 种 方法 ， 是 基于 v$sysstat 和 v$sesstat 视 图 ， 而 且 仅仅 是 
给 出 一 个 线索 提示 数据 库 中 的 某 处 存在 着 迁移 或 链接 的 行 。 其 思路 是 检查 名 为 table fetch continued 
row 的 统计 信息 ， 该 统计 信息 能 够 给 出 读 取 超过 一 个 以 上 行 片 断 (包括 块 内 链接 的 行 ) 的 提取 操作 的 
数量 。 这 个 统计 信息 也 可 以 与 table scan rows gotten 以 及 table fetch by rowid 作 对 比 ， 以 便 评估 行 
链接 和 行 迁 移 的 相对 影响 。 

比较 起 来 ,第 二 种 方法 会 给 出 关于 迁移 的 和 链接 的 行 的 精确 信息 。 遗 憾 的 是 , 它 要 求 为 每 张 潜 在 
包含 链接 的 或 迁移 的 行 的 表 执行 ANALYZE TABLE LIST CHAINED ROWS 语 句 。 如 果 找 到 链接 的 或 迁移 的 行 ， 
会 将 它们 的 rowid 插 入 到 chained_rows 表 中 。 然后 , 如 下 面 的 查询 所 示 , 根据 这 些 rowid 可 以 估算 这 些 行 
的 大 小 ， 基 于 此 ， 再 将 这 些 行 的 大 小 与 块 大 小 进行 比较 ， 就 可 以 识别 出 它们 是 否 是 迁移 或 链接 的 行 。 
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SELECT vsize(xco77>) + vSize(xcoZ2>) + ... + VSize( <¢co1n») 
FROM <¢table> 
WHERE rowid = "<¢rowid>' 


男 外 作为 一 种 选择 ， 也 可 以 查看 类 似 dba_tables 这 样 的 视图 中 的 avg_row_len 列 ， 当 做 粗略 估算 
如 果 平 均 行 大 小 接近 或 甚至 大 于 块 大 小 ， 则 很 有 可 能 存在 链接 的 行 。 


警告 ”正如 在 第 8 章 中 讨论 过 的 ， 类 似 dba tables 这 样 的 数据 字典 视图 中 的 chain cnt 列 本 应 提供 链 
接 的 和 迁移 的 行 数 量 。 遗 憾 的 是 ， 这 个 统计 信息 并 没有 被 dbms_stats 包 收集 。 如 果 没 有 设置 
chain_cnt， 程 序 包 会 将 它 设置 为 0。 否 则 ,程序 包 根本 不 会 修改 chain cnt。chain cnt.sql 
脚本 演示 了 这 种 行为 。 尽 管 使 用 正确 的 值 填充 chain_cnt 的 唯一 途径 是 执行 ANALYZE TABLE 
COMPUTE STATISTICS 语 名 ， 但 这 会 引起 被 分 析 的 表 的 所 有 对 象 统计 信息 都 被 发 盖 挤 。 所 以 不 
推荐 这 种 做 法 - 


16.3.4 解决 方案 


适用 于 避免 迁移 的 对 策 和 适用 于 避免 链接 的 那些 对 策 有 所 不 同 。 因 此 , 我 强调 一 下 ,在 采取 措施 
之 前 ， 必 须 查 明 问 题 是 由 迁移 还 是 链接 引起 的 

预防 行 迁移 是 可 行 的 。 这 只 是 正确 设置 PCTFREE 的 问题 , 或 者 换 句 话说 , 在 原始 的 块 中 保留 足够 的 
空闲 空间 ， 就 能 解决 完整 存储 修改 的 行 的 问题 。 这 种 方式 下 ， 如 果 已 经 断定 正在 遭遇 行 迁 移 ， 就 应 该 
增加 当前 PCTFREE 的 值 。 你 应 该 估算 平均 的 行 增长 幅度 以 便 选 择 一 个 合理 的 值 。 要 达到 这 个 目标 , 你 应 
该 知道 这 些 行 被 插入 时 的 平均 大 小 ， 以 及 当 它 们 不 再 被 更 新 的 时 候 的 平均 大 小 。 

要 从 一 张 表 中 移 除 迁 移 的 行 ， 有 两 种 可 能 性 。 首 先 ， 可 以 通过 导出 /导入 或 ALTER TABLE MOVE 来 彻 
底 整 理 这 张 表 。 其 次 ， 可 以 只 将 迁移 的 行 复制 到 一 张 临时 表 中 ， 然 后 在 原始 表 中 将 它们 删除 并 重新 插 
入 。 第 二 种 方法 在 只 有 一 小 部 分 的 行 被 迁移 ， 而 且 没有 足够 的 时 间或 资源 来 彻底 整理 一 张 表 的 时 候 尤 
其 有 用 。 

避免 行 链接 则 要 困难 得 多 。 显 而 易 见 的 解决 方案 是 使 用 更 大 的 块 大 小 。 然 而 有 时 候 ， 即 使 最 大 的 
块 大 小 也 是 不 够 大 的 。 此 外 ， 如 果 链 接 是 因为 列 的 数量 超过 了 255， 那 么 只 有 重新 设计 才 有 用 。 因 此 ， 
在 某 些 情况 下 ， 这 个 问题 唯一 可 行 的 解决 方案 ， 是 将 不 经 常 访问 的 列 放 管 在 表 的 末尾 ， 从 而 避免 每 次 
都 扫描 所 有 的 行 片断 。 


16.4” 块 争 用 


块 争 用 .会 在 多 个 进程 同一 时 间 争 相 访问 相同 的 块 时 出 现 ， 能 够 导致 应 用 程序 性 能 低下 。 块 争 用 
有 时 可 以 通过 操纵 表 或 索引 的 物理 存储 参数 来 减轻 。 本 节 会 讲述 在 哪些 情况 下 应 用 程序 会 遭遇 块 争 
用 ， 并 会 介绍 如 何 识别 和 预防 这 个 问题 。 


16.4.1 问题 描述 
缓冲 区 缓存 在 属于 同一 数据 库 实例 的 所 有 进程 之 间 共 享 。 因此 ， 多 个 进程 可 能 会 需要 同时 读 取 或 
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修改 在 缓冲 区 缓存 中 存储 的 相同 块 。 为 避免 访问 冲突 ， 每 个 进程 在 能 够 访问 缓冲 区 缓存 中 的 块 之 前 ， 
必须 在 这 个 块 上 持 有 一 个 Pin ( 这 个 规则 也 有 例外 的 情况 , 但 是 对 于 本 节 的 目的 而 言 , 讨论 它们 并 不 重 
要 )。Pin 是 一 种 短暂 锁 ， 被 进程 以 共享 或 独占 模式 持 有 。 在 一 个 给 定 的 块 上 ， 可 能 会 有 多 个 进程 以 共 
享 模式 持 有 Pin ( 例如 ， 如 果 它 们 都 只 是 想 读 取 这 个 数据 块 )， 而 只 能 有 一 个 单独 的 进程 能 够 以 独占 模 
式 持 有 Pin ( 需要 修改 此 块 )。 一 旦 有 进程 想 要 持 有 的 Pin 与 其 他 进程 持 有 的 Pin 冲 突 ， 它 就 必须 进入 等 
待 。 此 时 这 个 进程 就 会 面临 块 争 用 。 


注意 ”在 能 够 Pin 或 取消 Pin 一 个 块 之 前 ,进程 必须 获得 保护 该 块 的 缓存 缓冲 区 链 的 门 锁 。 由 于 这 个 原 
因 ， 可 能 会 出 现 块 争 用 被 门 锁 争 用 掩盖 或 伴随 着 门 锁 争 用 一 起 发 生 的 情况 。 


16.4.2 ”问题 识别 


如 果 遵 从 本 书 第 二 部 分 提供 的 建议 , 识别 块 争 用 问题 唯一 有 效 的 方式 是 衡量 因 块 争 用 损失 了 多 少 
时 间 。 出 于 这 个 目的 ， 应 该 检查 应 用 程序 是 否 遭 遇 了 与 块 争 用 相关 的 等 待 事件 ， 也 就 是 buffer busy 
waits。 实 际 上 ， 遭 遇 块 争 用 的 进程 会 等 待 这 个 事件 。 因 此 ， 如 果 这 个 事件 作为 相关 组 件 出 现在 资源 
使 用 率 配 置 文件 中 , 那么 这 个 应 用 程序 正在 遭受 块 争 用 带 来 的 影响 。 在 这 种 情况 下 要 排查 故障 ， 需 要 
以 下 信息 : 
口 遭遇 等 竺 事件 的 SQL 语句 
口 等 待 出 现在 哪个 段 上 
口 等 待 是 在 哪 种 类 型 的 块 上 发 生 的 
正如 在 第 二 部 分 中 描述 的 ， 获 取 所 需 信息 的 最 佳 方式 取决 于 问题 种 类 。 问 题 是 可 重 现 的 还 是 
不 可 重 现 的 ? 对 于 不 可 重 现 的 问题 ， 分 析 是 实时 执行 的 还 是 事后 执行 的 ?此 外 ， 还 应 该 考虑 授权 
需求 ， 例 如 ， 你 有 没有 Diagnostic Pack 诊 断 包 的 授权 。 还 有 一 点 很 重要 ， 就 是 要 认识 到 并 非 第 二 
部 分 中 描述 的 所 有 技巧 都 适合 精确 诊断 块 争 用 问题 。 事 实 上 ， 尽 管 可 以 通过 使 用 基于 动态 性 能 视 
图 的 技术 ( 例如 ，Snapper 或 Active Session History ) 和 SQL 跟踪 明确 地 识别 块 争 用 问题 ， 但 当 你 
遇 到 涉及 某 些 不 确定 性 的 情况 时 ,使 用 基于 AWR 和 Statspack 报 告 的 技巧 就 不 行 了 。 这 是 因为 有 以 
下 两 个 主要 的 原因 。 
口 系统 级 别 的 分 析 只 能 精确 到 与 影响 整个 系统 有 关 的 问题 。 因 此 ， 你 可 能 会 错过 只 影响 几 个 会 
话 的 问题 。 
口 AWR 和 Statspack 报 告 基 于 一 组 动态 性 能 视图 所 提供 的 信息 ， 而 这 些 动 态 性 能 视图 无 法 一 直 保 
持 收 集 数据 。 为 了 验证 这 个 限制 ,我 们 看 一 下 v$waitstat 视 图 ( 下面 的 查询 作为 一 个 例子 显示 
了 它 提供 的 信息 )。 尽 管 这 个 视图 的 内 容 提供 了 所 需 的 关于 等 待 出 现在 哪些 类 型 的 块 上 的 信 
息 , 但 是 还 是 没有 办 法 确定 有 哪些 SQL 语句 在 等 待 这 些 块 ( 注意 这 个 视图 中 的 所 有 列 都 被 显示 
出 来 了 )。 
SQL> SELECT * FROM v$waitstat; 


data block 102011 5162 
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sort block 0 0 
save undo block 0 0 
segment header 76053 719 
save Undo header 0 

free list 3265 12 
extent map 0 

1st level bmb 6318 352 
2nd level bmb 185 3 
3rd level bmb 0 0 
bitmap block 0 0 
bitmap index block 0 0 
file header block 389 2069 
unused 0 0 
system undo header 1 
system undo block 0 0 
undo header 3244 70 
undo block 38 ps 


注意 关于 v$waitstat 视 图 需要 理解 的 核心 内 容 是 关于 块 类 型 的 class 列 ， 而 不 是 发 生 等 待 的 数据 类 
型 或 结构 。 例 如 ， 如 果 争 用 是 因为 包含 在 段 头 块 中 的 自由 列表 引起 的 ， 则 报告 会 体现 等 待 是 
发 生 在 Segment header 类 下 ， 而 不 是 在 free list 类 下 。 事 实 上 ，free 1ist 适 用 于 只 存储 自由 
列表 信息 的 数据 块 ( 这样 的 块 是 在 将 FREELIST GROUPS 的 值 设置 为 大 于 1 时 被 创建 出 来 的 ) 另 
一 个 例子 是 关于 索引 的 。 如 果 存 储 索 引 的 块 发 生 争 用 ， 则 会 在 data block 类 下 报告 等 待 。 


根据 刚刚 解释 的 原因 ， 接 下 来 的 两 部 分 会 提供 使 用 SQL 跟踪 和 v$session 视 图 ( 基于 Snapper; 在 
本 例 中 , Active Session History 不 是 很 合适 , 因为 我 使 用 的 测试 只 会 持续 运行 几 秒 钟 ) 识别 问题 的 例子 。 
在 这 些 列子 中 使 用 的 块 争 用 是 通过 buffer_busy_waits.sql 脚 本 生成 的 。 


1. 使 用 SQL 跟 踪 

我 建议 使 用 TVD$XTAT 来 处 理 puffer busy waits.sql 脚 本 生成 的 跟踪 文件 。 尽 管 可 以 选择 使 用 
TKPROF 或 TVD$XTAT 中 的 任何 一 个 ， 但 我 还 是 推荐 后 者 。 这 是 因为 TKPROF 不 会 为 你 提供 排查 块 争 
用 问题 所 需 的 全 部 信息 。 尤 其 是 ， 它 不 提供 关于 遭遇 buffer busy waits 的 块 的 信息 。 

由 TVDSXTAT 为 当前 的 例子 生成 的 输出 文件 ， 以 及 它 依 赖 的 跟踪 文件 ， 都 在 
buffer busy waits.zip 文 件 中 提供 ， 这 些 文件 显示 其 中 一 条 SQL 语句 即 一 条 UPDATE 语 句 ) 几乎 是 整 
个 响应 时 间 的 元 多。 下 面 的 摘录 显示 该 UPDATE 语 句 的 执行 统计 信息 。 通 过 10 000 次 执行 ,测量 出 消耗 
的 时 间 为 6.187 秒 ， 其 中 CPU 时 间 为 2.411 秒 。 


UPDATE /*+ index(t) */ T SET D = SYSDATE WHERE ID = :B1 AND N10 = ID 


Call Count Misses (CPU Elapsed PIO LIO Consistent Current Rows 


Parse 1 10.001 0.000 0 0 0 0 0 
Execute 10,000 12.410 6.186 0 73,084 43,797 29,287 10,000 
Fetch 0 00.000 0.000 0 0 0 0 0 


Total 10,001 22.411 6.187 0 73,084 43,797 29,287 10,000 
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因为 CPU 时 间 只 占 响应 时 间 的 39%， 有 必要 看 一 下 处 理 过 程 中 出 现 的 等 待 ， 以 便 找 出 时 间 是 如 何 
花费 掉 的 。 下 面 的 摘录 精确 地 显示 了 这 个 信息 。 你 可 以 看 到 最 大 的 消耗 者 ， 是 花费 了 3.322 秒 的 buffer 
busy waits。 还 要 注意 ， 在 这 个 特定 的 例子 中 ，cache buffers chains 门 锁 拥 有 最 小 的 争 用 。 


Total Number of Duration per 
Component Duration % Events Event 
buffer busy waits 3.322 53.843 10,953 0.000 
CPU 2.410 39.056 n/a n/a 
latch: In memory undo latch 0.278 4.509 6,389 0.000 
latch: cache buffers chains 0.158 2.559 6,238 0.000 
recursive statements 0.001 0.016 n/a n/a 
enq: HW - contention 0.000 0.008 3 0.000 
Disk file operations 1/0 0.000 0.007 1 0.000 
latch free 0.000 0.001 1 0.000 
Total 6.170 100.000 


在 TVD$XTAT 中 提供 的 额外 信息 ， 但 在 TKPROF 的 输出 中 却 缺失 的 信息 ， 是 一 个 包含 着 在 哪些 块 
上 出 现 了 等 待 的 列表 。 下面 的 摘录 显示 , 在 此 处 所 分 析 的 案例 中 , 这 样 一 个 列表 看 起 来 是 什么 样子 的 。 
你 可 以 看 到 超过 99% 的 buffer busy waits 出 现在 文件 4 中 的 编号 为 836 775 的 块 上 。 还 要 注意 遭遇 争 用 
的 块 只 是 一 个 数据 块 。 


File Block Total Number of Duration per 

Number Number Duration % Events % Event Class 

4 836,775 3.290 99.045 9,779 89.281 336 data block (1) 

3 272 0.006 0.173 196 1.789 29 undo header (35) 
3 192 0.003 0.094 108 0.986 29 undo header (25) 
3 128 0.003 0.094 117 1.068 27 undo header (17) 
3 256 0.003 0.090 122 1.114 24 undo header (33) 
3 144 0.003 0.088 88 0.803 33 undo header (19) 
3 208 0.003 0.083 99 0.904 28 undo header (27) 
3 240 0.003 0.083 112 1.023 24 undo header (31) 
3 176 0.003 0.082 105 0.959 26 undo header (23) 
3 224 0.003 0.081 107 0.977 25 undo header (29) 
Total 3.322 100.000 10,953 100.000 303 


根据 此 信息 ， 可 以 通过 以 下 查询 找 出 发 生 等 待 的 段 的 名 称 ( 小 心 ， 这 个 查询 的 执行 可 能 会 占用 大 
量 资源 ): 
SOL> SELECT owner, segment name, segment type 
2 FROM dba extents 


3 WHERE file id = 4 
4 AND 836775 BETWEEN block id AND block id+blocks-1; 


OWNER SEGMENT NAME SEGMENT_ TYPE 


CHRIS T TABLE 
概括 起 来 ， 整 个 分 析 提 供 以 下 信息 。 
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口 遭遇 等 待 的 SQL 语句 是 一 个 UPDATE 语 句 。 
口 大 多 数 时 候 ， 等 待 出 现在 一 个 单独 的 数据 块 上 。 
口 发 生 等 待 的 段 是 UPDATE 语句 中 被 更 新 的 表 。 


2. 使 用 Snapper 

通过 Snapper， 可 以 根据 几 个 准则 收集 数据 。 但 是 ,假如 你 已 经 识别 出 必须 要 排查 故障 的 会 话 ， 最 
好 通过 执行 类 似 下 面 的 例子 中 展示 的 这 条 命令 着 手 , 在 本 例 中 ,我 指定 针对 所 有 会 话 执 行 buffer_busy_ 
waits.sql 脚 本 。 就 像 输 出 显示 的 那样 ,一 条 SQL 语句 ( 9bjs886z43g7k ) 不 仅 消耗 了 大 部 分 的 数据 库 时 
间 (在 采样 期 间 ， 总 计 有 7 个 活跃 的 会 话 )， 而 且 在 此 情况 下 ， 它 还 遭遇 了 大 量 的 buffer busy waits. 


SQL> @snapper.sql ash=sql_id+wait_ class+event 1 1 user=chris 


Active% | SQL ID | WAIT_CLASS | EVENT 


560% | 9bjs886z43g7k | Concurrency | buffer busy waits 


100% | 9bjs886z43g7k | ON CPU | ON CPU 
40% | 091f2847g34rm | ON CPU | ON CPU 
20% | 48gc5511n38a1 | ON CPU | ON CPU 


20% | 9bjs886z43g7k | Concurrency | latch: cache buffers chains 
20% | 9bjs886z43g7k | Concurrency | latch: In memory undo latch 


10% | 93053g60rwzOx | ON CPU | ON CPU 
10% | | ON CPU | ON CpU 
10% | cktrdz5u39r04 | ON CPU | ON CPU 


10% | 93053860rwzOx | Concurrency | latch: In memory undo latch 


接 下 来 ， 可 以 使 用 dbms_xplan 包 来 获取 问题 SQL 语句 的 文本 和 执行 计划 。 不 出 所 料 ， 正 是 上 一 小 
节 中 识别 出 的 同一 条 UPDATE 语 句 。 


SQL> SELECT * FROM table(dbms xplan.display cursor('9bjs886z43g7k', 0, "basic )); 


UPDATE /*+ index(t) */ T SET D = SYSDATE WHERE ID = :B1 AND N10 = ID 


| Id | 0peration | Name | 


| 0 | UPDATE STATEMENT | 

| 1 | UPDATE | 守 
| 2 | TABLE ACCESS BY INDEX RONID| T 
| 3| INDEX UNIOUE SCAN | 


为 了 深入 调查 buffer busy waits， 可 以 再 次 执行 Snapper， 就 像 下 面 例 子 中 这 样 ， 但 是 这 一 次 使 用 
一 组 参数 执行 它 ， 以 便 显示 关于 buffer busy waits 的 详细 信息 。 注 意 ， 对 于 buffer busy waits， 与 这 
个 事件 有 关 的 参数 有 以 下 含义 : p1 是 文件 号 ( 4 )，p2 是 块 号 ( 836775 ), 还 有 p3 是 遭遇 等 待 的 块 类 ( 1= 
数据 块 )。 


SQL> @snapper.sql ash=event+p1+p2+p3 1 1 user=chris 
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560% | buffer busy waits | .4 | 836775 总 
190% | ON CPU | | | 
20% | latch: cache buffers chains | 1992028296 | 155 【 翅 
20% | latch: In memory undo latch | 1966009168 | 251 | 0 
10% | latch: In memory undo latch | 1966009648 | 251 | 
概括 起 来 ， 使 用 Snapper 的 分 析 准 确 地 描述 了 在 使 用 SQL 跟踪 时 识别 出 的 一 模 一 样 的 问题 。 


16.4.3 ”解决 方案 


通过 识别 遭遇 等 待 的 SQL 语句 、 块 类 以 及 段 ， 应 该 能 够 识别 出 问题 的 根本 原因 。 接 下 来 我 们 来 讨 
论 一 些 关 于 常见 块 类 的 典型 案例 。 


1. 数据 块 的 争 用 

所 有 用 来 组 成 表 或 索引 段 且 不 用 于 存储 元 数据 ( 例如 段 头 ) 的 块 称 作 数 据 块 。 它 们 的 争 用 源 自 两 
个 主要 原因 。 第 一 个 是 在 给 定 的 段 上 高 频率 的 数据 块 访问 。 第 二 个 是 高 频率 的 执行 。 乍 一 看 ， 这 两 个 
是 同一 回 事 。 为 什么 它们 实际 上 是 不 同 的 ， 需 要 做 出 一 些 解释 。 在 第 一 种 情况 中 ， 问 题 的 起 源 是 低 效 
率 的 执行 计划 引起 对 某 些 块 执行 高 频率 的 数据 块 访问 。 通常 , 这 是 因为 低 效率 的 关联 组 合 操作 ( 例如 ， 
嵌 套 循环 链接 ) 引起 。 在 此 情况 下 ,即使 具有 两 条 或 三 条 SQL 语句 并 发 执行 也 有 可 能 引发 争 用 。 相 反 ， 
在 第 二 种 情况 中 , 问题 的 起 源 是 在 同一 时 刻 非常 频繁 地 执行 访问 同一 个 块 的 多 条 SQL 语句 。 换 句 话 说， 
针对 (少量 ) 块 执行 SQL 语句 的 并 发 数量 是 问题 所 在 。 也 有 可 能 出 现 两 者 同时 发 生 的 情况 。 如 果 两 个 
问题 同时 出 现 ， 在 处 理 第 二 个 问题 之 前 要 处 理 好 第 一 个 问题 。 实 际 上 ， 当 第 一 个 问题 消失 的 时 候 ， 第 
二 个 问题 可 能 也 就 不 见 了 。 

要 解决 第 一 个 问题 ， 有 必要 进行 SQL 优化 。 必 须 产生 一 个 高 效 的 执行 计划 以 取代 低 效 的 那个 。 当 
然 了 ， 在 某 些 情况 下 ， 说 起 来 容易 做 起 来 难 。 不 管 怎样 ， 这 的 确 是 你 必须 要 解决 的 事情 。 

要 解决 第 二 个 问题 ， 有 多 种 途径 。 要 使 用 哪 种 途径 取决 于 SQL 语句 的 类 型 ( 即 DELETE 、INSERT、 
SELECT 以 及 UPDATE ) 和 段 的 类 型 ( 即 表 或 索引 )。 但是， 在 开始 之 前 ， 当 执行 的 频率 很 高 的 时 候 ， 你 
应 该 总 是 问 这 样 一 个 问题 : 是 不 是 真 的 有 必要 如 此 频繁 地 针对 相同 的 数据 执行 那些 SQL 语句 ? 实际 
上 ， 应 用 程序 ( 例如 ， 实 现 了 某 种 轮 询 的 应 用 ) 过 于 频繁 地 执行 没有 必要 的 相同 SQL 语句 并 不 是 稀奇 
的 事 。 如 果 无 法 降低 执行 的 频率 ， 则 存在 以 下 可 能 性 。 注 意 , 在 大 多 数 情况 下 ， 方 法 是 通过 大 量 的 块 
来 分 散 这 些 活动 以 解决 此 问题 。 唯 一 的 例外 是 当 多 个 会 话 等 待 相 同行 的 时 候 。 

口 如 果 在 一 张 表 的 块 上 出 现 争 用 是 因为 DELETE 、SELECT 以 及 UPDATE 语 句 ， 应 该 减少 每 个 块 上 的 行 
数量 。 注 意 这 样 做 与 通常 在 每 个 块 中 填 人 尽 可 能 多 数量 的 行 的 最 佳 实践 相 反 。 要 在 每 个 块 中 
存储 更 少 的 行 ， 要 么 使 用 较 高 的 PCTFREE， 要 不 然 就 使 用 较 小 的 块 大 小 。 

口 如 果 在 一 张 表 的 块 上 出 现 争 用 是 因为 INSERT 语 句 , 并 且 使 用 了 自由 列表 段 空 间 管理 , 则 可 以 增 
加 自由 列表 的 数量 。 事 实 上 ， 使 用 多 个 自由 列表 的 目的 ， 恰 恰 是 通过 多 个 块 来 分 散 并 发 执行 
的 INSERT 语 句 。 男 外 一 个 可 行 的 方法 是 将 段 迁 移 到 使 用 自动 段 空间 管理 的 表 空 间 中 。 

口 如 果 在 索引 块 上 出 现 了 争 用 ， 有 两 种 可 行 的 解决 方案 。 第 一 个 ， 可 以 使 用 REVERSE 选 项 创建 索 
引 。 但 是 注意 ， 如 果 争 用 出 现在 索引 的 根 块 上 ， 这 个 方法 一 点 用 也 没有 。 第 二 个 ， 索 引 可 以 


QO SELECT 语句 在 两 种 情况 下 修改 块 : 第 一 ， 当 指定 了 FOR UPDATE 选 项 时 ; 第 二 ， 当 延迟 块 清除 出 现时 。 四 
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使 用 散 列 分 区 ( 或 子 分 区 )， 散 列 要 基于 索引 键 的 前 导 列 ( 这 样 会 创建 多 个 根 块 ， 所 以 能 够 缓 
解 访问 一 个 单独 的 分 区 时 根 块 争 用 的 情况 )。 
关于 反 转 索引 值得 注意 的 是 ， 在 这 些 索 引 上 执行 的 范围 扫描 无 法 应 用 基于 范围 条 件 的 限制 条 件 
(例如 ，BETAEEN、> 或 <= )。 当 然 ， 等 价 谓词 是 受 支持 的 。 下 面 的 例子 ,来自 reverse_index.sql 脚 本， 
展示 了 在 使 用 REVERSE 选 项 重建 索引 后 ， 查 询 优 化 器 不 再 继续 使 用 该 索引 的 情形 : 


SQL> SELECT * FROM t WHERE n < 10; 


0 | SELECT STATEMENT | 
1 | TABLE ACCESS BY INDEX ROWID| T | 
2 | INDEX RANGE SCAN | | 


2 - access("N"<10) 
SQL> ALTER INDEX t i REBUILD REVERSE; 


SQL> SELECT * FROM 七 WHERE n < 10; 


| 0 | SELECT STATEMENT | | 
|* 1 | TABLE ACCESS FULL|IT | 
1 - filter("N"<10) 
注意 ,在 这 种 情况 下 hint 也 不 会 有 帮助 。 数 据 库 引擎 就 是 无 法 在 一 个 反 转 索引 上 通过 索引 范围 扫 
描 应 用 范围 条 件 。 因 此 ， 下 面 的 例子 证 实 了 如 果 你 尝试 强制 查询 优化 器 使 用 索引 访问 ， 则 优化 器 会 使 
用 索引 全 扫描 : 


SQL> SELECT /*+ index(t) */ * FROM t WHERE n < 10; 


0 | SELECT STATEMENT | | 
1 | TABLE ACCESS BY INDEX ROWID| T | 
2 | INDEX FULL SCAN 直下 


2 - filter("N"<10) 


2. 段 头 块 的 争 用 

每 个 表 和 索引 段 都 有 一 个 段 头 块 。 这 个 块 包含 以 下 元 数据 : 关于 段 的 高 水 位 线 的 信息 、 组 成 段 的 
扩展 的 列表 ， 以 及 关于 空闲 空间 的 信息 。 为 管理 空闲 空间 ， 段 头 块 包含 〈 取决 于 使 用 的 段 空间 管理 类 
型 ) 自由 列表 或 一 个 包含 着 自动 段 空间 管理 信息 的 块 的 列表 。 通 常 ， 当 多 个 进程 同时 修改 段 头 块 的 内 
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容 时 会 遭遇 争 用 。 注 意 ， 在 以 下 情况 下 会 修改 段 头 块 : 

口 如 果 INSERT 语 句 使 得 段 头 块 有 必要 增加 高 水 位 线 ; 

口 如 果 INSERT 语 名 使 得 段 头 块 有 必要 分 配 新 的 扩展 ; 

口 如 果 DELETE 、INSERT 和 UPDATE 语 名 使 得 段 头 块 有 必要 修改 自由 列表 。 

针对 以 上 这 些 情 况 ， 一 个 可 能 的 解决 方案 是 给 这 个 段 分 区 ， 以 便 将 负载 分 散 至 多 个 段 头 块 上 。 大 
多 数 时 候 ， 这 可 以 通过 散 列 分 区 来 实现 ， 尽 管 这 样 ， 根 据 负载 和 分 区 键 的 不 同 ， 其 他 的 分 区 方法 也 可 
能 是 可 行 的 。 但 是 ， 如 果 问 题 是 由 第 二 或 第 三 种 情况 引起 的 ， 则 存在 其 他 解决 方案 。 对 于 第 二 种 ， 应 
该 直接 使 用 更 大 的 扩展 。 通 过 这 种 方式 ， 很 少 会 分 配 新 的 扩展 。 对 于 第 三 种 ,借助 于 自由 列表 组 ， 可 
以 将 自由 列表 移动 到 其 他 块 中 ,但 这 不 适用 于 使 用 自动 段 空间 管理 的 表 空间 。 事 实 上 ， 当 使 用 了 多 个 
自由 列表 组 时 ， 自 由 列表 就 不 再 位 于 段 头 块 中 ( 它们 被 分 散 到 由 参数 FREELIST GROUPS 指 定 的 值 相等 数 
量 的 块 中 ， 这 样 就 可 以 期 待 有 较 少 的 争 用 出 现在 它们 头 上 ， 你 不 能 简单 地 将 争 用 转移 至 其 他 地 方 )。 
另 一 种 可 能 性 是 使 用 自动 段 空间 管理 的 表 空 间 代 替 自 由 列表 段 空 间 管理 。 


注意 “自由 列表 组 只 有 在 使 用 真实 应 用 程序 群集 时 才 有 用 , 这 是 Oracle 数 据 库 领 域 一 个 广 为 流 传 的 神 
话 。 这 是 错误 的 。 自 由 列表 组 在 每 种 数据 库 中 都 有 用 。 我 强调 这 一 点 是 因为 曾经 读 到 或 听 到 
过 太 多 关于 这 个 问题 的 错误 描述 了 。 


3. Undo 头 和 Undo 块 的 争 用 

这 些 类 型 的 块 争 用 会 在 两 种 情况 下 出 现 。 第 一 种 ， 仅 对 于 undo 头 块 来 说 ， 是 当 只 有 少量 undo 段 可 
用 而 且 并 发 提交 (或 初始 化 或 回 深 ) 大 量 事务 的 时 候 。 这 个 问题 只 有 在 使 用 手动 ndo 管 理 的 时 候 才 会 
出 现 。 换 名 话说 ， 这 种 情况 一 般 只 有 在 数据 库 管 理 员 手动 创建 回 滚 段 时 才 会 发 生 。 要 解决 这 个 问题 ， 
应 该 使 用 自动 undo 管 理 。 第 二 种 是 当 多 个 会 话 在 同一 时 间 修 改 并 查询 相同 块 的 时 候 。 此 时 会 导致 数据 
库 引 擎 创建 大 量 的 一 致 性 读 块 ,并 且 因 此 需要 同时 访问 这 个 块 以 及 与 它 关 联 的 undo 块 。 在 这 种 情况 下 
可 以 做 的 事情 很 少 ， 只 有 减少 数据 块 的 并 发 性 ， 继 而 同时 减少 undo 块 的 并 发 性 。 


4. 扩展 映射 块 的 争 用 

正如 在 之 前 的 “ 段 头 块 的 争 用 ”部 分 中 讨论 的 ， 段 头 块 包含 一 个 组 成 段 的 扩展 的 列表 。 如 果 该 列 
表 在 段 头 中 装 不 下 , 它 就 会 分 散在 多 个 块 中 : 段 头 块 加 上 一 个 或 多 个 扩展 映射 块 。 扩 展映 射 块 (extent 
map block ) 会 在 并 发 执行 INSERT 语 句 导致 频繁 分 配 新 的 扩展 的 时 候 遭 遇 争 用 。 要 解决 这 个 问题 ， 应 该 
使 用 更 大 的 扩展 。 


5. 自由 列表 块 的 争 用 

正如 在 之 前 的 “ 段 头 块 的 争 用 ”部 分 中 讨论 的 ， 借 助 于 自由 列表 组 ， 可 以 将 自由 列表 移动 到 其 他 
块 中 ， 这 些 块 称 作 自由 列表 块 。 当 并 发 DELETE 、INSERT 或 UPDATE 语 句 导 致 频繁 修改 自由 列表 时 ， 自 由 
列表 块 就 会 遭遇 争 用 。 要 解决 这 个 问题 ， 应 该 增加 自由 列表 组 的 数量 。 另 外 一 种 可 能 性 是 使 用 自动 段 
空间 管理 的 表 空 间 代 替 自 由 列表 段 空 间 管 理 。 
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16.5 ”数据 压缩 


通常 压缩 数据 的 目标 是 节省 磁盘 空间 。 既 然 我 们 正在 考虑 性 能 问题 ,本 节 会 介绍 数据 压缩 经 常 被 
遗忘 的 另 一 个 优势 : 缩短 响应 时 间 。 


16.5.1 概念 


利用 数据 压缩 来 实现 更 好 性 能 的 思想 源 于 一 个 简单 的 概念 。 如 果 一 个 SQL 语句 必须 通过 全 表 (或 
分 区 ) 扫描 处 理 大 量 的 数据 ， 则 资源 使 用 的 大 户 很 有 可 能 就 是 与 磁盘 IO 相关 的 操作 。 在 这 种 情况 下 ， 
降低 从 磁盘 读 取 的 数据 总 量 将 会 改进 性 能 。 实 际 上 ， 人 性 能 应 该 按压 缩 因 子 成 比例 增加 。 下 面 来 自 
data_compression.sql 脚 本 的 例子 ， 证 实 了 这 一 点 : 


SQOL> CREATE TABLE 七 NOCOMPRESS AS 

2 WITH 

3 t AS (SELECT /*+ materialize */ rownum AS n 

4 FROM dual 

5 CONNECT BY level <= 1000) 

6 SELECT rownum AS n, rpad(' ',500,mod(rownum,15)) AS pad 

了 RON hy; 直 

8 WHERE rownum <= 1E7; 
SOL> execute dbms stats.gather table stats(ownname=>user, tabname=>'t') 
SQL> SELECT table name, blocks FROM user tables WHERE table name = 'T'; 
TABLE_NAME BLOCKS 
T 715474 
SQL> SELECT count(n) FROM t; 

COUNT(N) 

10000000 
Elapsed: 00:00:27.91 
SQL> ALTER TABLE 七 MOVE COMPRESS; 
SQL> execute dbms stats.gather table stats(ownname=>user, tabname=>'t') 
SQL> SELECT table name, blocks FROM user tables WHERE table name = 'T'; 
TABLE_NAME BLOCKS 


SQL> SELECT count(n) FROM +t; 


COUNT(N) 
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10000000 
Elapsed: 00:00:05.38 
SQL> SELECT 715474/140367, 27.91/05.38 FROM dual; 


715474/140367 27.91/05.38 


5.09716671 5.18773234 
为 了 在 完全 扫描 操作 中 利用 数据 压缩 ， 正 如 在 之 前 的 例子 中 所 示 ( 换 句 话说 ,为 了 使 完全 扫描 操 
:运行 得 更 快 )， 可 能 有 必要 节约 CPU 资 源 。 这 不 是 因为 “解压 缩 ” 这 些 块 时 的 CPU 负 载 ( 其 实 此 负 
载 很 小 ， 因 为 默认 的 压缩 基于 一 种 非常 简单 的 算法 ， 只 会 对 重复 的 列 值 去 重 )， 而 是 因为 由 SQL 引擎 
执行 的 操作 ( 在 之 前 的 例子 中 ， 是 访问 这 些 块 和 计数 的 操作 ) 会 在 更 短 的 时 间 内 执行 。 还 要 注意 , 减 
少 物理 1O 操 作 的 数量 也 可 以 减少 CPU 消耗 。 例 如 , 在 我 的 测试 系统 上 ， 在 执行 测试 查询 期 间 , 不 使 用 
压缩 时 会 话 级 别 的 平均 CPU 使 用 率 大 约 是 18%， 而 使 用 压缩 后 大 约 是 27%6。 


16.5.2 ”要 求 


Oracle 数 据 库 企业 版 〈 而 非 其 他 任何 版 本 ) 提供 多 种 数据 压缩 方法 。 此 外 ， 其 中 一 部 分 算法 只 在 
特定 的 版 本 中 可 用 ; 其 他 的 版 本 受 授权 的 问题 限制 。 表 16-2 总 结 了 各 个 版 本 都 提供 了 哪些 方法 ， 以 及 
使 用 它们 的 授权 要 求 。 


表 16-2 ”由 Oracle 数 据 库 提 供 的 压缩 方法 


方 法 版 本 授权 要 求 
基础 表 压 缩 从 9.2 开始 车 
高 级 行 压缩 ( 也 就 是 OLTP 表 压缩 ) 。 从 11.1 开 始 高 级 压缩 选项 
混合 列 压缩 从 11.2 开始 包含 数据 的 表 空间 必须 迁移 至 Exadata 存 储 、ZFS 存 储 或 Pillar 
Axiom 600 存 储 中 


一 种 数据 压缩 方法 是 否 能 应 用 还 取决 于 准备 进行 压缩 的 表 的 实现 。 具 体 来 说 ， 有 以 下 几 个 限制 。 
口 只 有 堆 表 可 以 被 压缩 ( 索引 组 织 表 、 外 部 表 以 及 属于 群集 的 一 部 分 表 都 不 受 支 持 )。 

口 除了 混合 列 压缩 ， 压 缩 的 表 不 能 拥有 超过 255 个 列 。 

口 压缩 的 表 不 能 拥有 LONG 或 LONG RAW 类 型 的 列 。 

口 压缩 的 表 不 能 启用 行 级 别 依赖 跟踪 。 

口 压缩 的 表 不 能 属于 sys 用 户 或 被 存储 在 system 表 空间 中 。 


16.5.3 方法 


为 了 对 表 16-2 中 提 到 的 三 种 方法 之 间 的 区 别 进行 总 体 描述 ,我们 来 快速 看 一 下 它们 的 关键 特性 ， 
以 及 应 该 在 什么 时 候 去 应 用 它们 。 
基础 表 压缩 是 Oracle 引 入 的 第 一 种 压缩 方法 。 要 使 用 这 种 方法 , 必须 通过 直接 路 径 接口 执行 加 载 。 
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换 句 话说 ， 仅 在 使 用 以 下 操作 之 一 时 ， 基 础 表 压 缩 才 会 压缩 数据 块 : 

口 CREATE TABLE ... COMPRESS ... AS SELECT ... 

口 ALTER TABLE ... MOVE COMPRESS 

口 INSERT /*+ append */ INTO ... SELECT ... 

口 INSERT /*+ parallel(...) */ INTO ... SELECT ..， 

口 由 应 用 程序 使 用 OCI 直 接 路 径 接 口 执行 的 加 载 ( 例如 SQL*Loader 实 用 工具 ) 

为 了 确保 在 每 个 块 中 尽 可 能 多 地 存储 数据 , 当 使 用 基础 表 压 缩 时 , 数据 库 引擎 默认 将 PCTFREE 设 置 
为 0。 假如 数据 是 通过 正常 的 INSERT 语 句 插 入 的 , 它 会 存储 在 没有 压缩 的 块 中 。 基 础 表 压 缩 还 有 一 个 劣 
势 ， 就 是 通常 不 仅 UPDATE 语 句 会 使 得 更 新 的 行 存储 在 没有 压缩 的 块 中 从 而 导致 行 迁移 ， 而 且 由 DELETE 
语句 造成 的 压缩 块 中 的 空闲 空间 一 般 也 不 会 被 重新 利用 。 出 于 这 些 原 因 ， 我 建议 只 在 (主要 用 于 ) 只 
读 的 段 上 使 用 基础 表 压 缩 。 举 例 来 说 ， 在 一 个 存储 着 很 长 历史 数据 的 分 区 表 中 ,而 且 只 有 最 近 的 少数 
几 个 分 区 会 被 修改 ， 压 缩 ( 主要 用 于 ) 只 读 分 区 可 能 有 所 帮助 。 数 据 集 市 和 完全 刷新 的 物化 视图 使 用 
基础 表 压 缩 也 是 不 错 的 选择 。 

引入 高 级 行 压缩 的 主要 目的 是 通过 提供 接近 于 基础 表 压 缩 ( 内 部 存储 基本 一 样 ) 的 压缩 比例 , 来 
支持 同时 受到 普通 插入 和 修改 ( 例如 来 自 UPDATE 和 DELETE 语 句 的 ) 问题 困扰 的 表 。 因 为 这 种 压缩 方法 
工作 的 方式 是 动态 的 ( 并 不 会 针对 每 个 INSERT 语 句 或 修改 都 进行 数据 压缩 ; 相反 ,会 在 给 定 的 块 中 包 
含 足 够 的 未 压缩 数据 时 进行 数据 压缩 )， 很 难 给 出 关于 它 的 使 用 建议 。 还 有 几 种 情况 高 级 行 压缩 的 表 
现 也 不 优 于 基础 表 压 缩 。 此 外 ,使 用 高 级 行 压缩 ， 会 比 未 压缩 的 表 产 生 更 多 的 undo 和 redo。 因 此 ， 为 
了 和 弄 清楚 高 级 行 压缩 是 否 能 够 正确 地 处 理 ( 多 数 时 候 ) 非 只 读数 据 ， 我 强烈 建议 你 首先 根据 预期 的 负 
载 仔 细 地 进行 测试 。 

混合 列 压 缩 则 基于 完全 不 同 的 技术 。 关 键 区 别 是 ， 对 于 一 个 具体 行 来 说 不 再 顺序 地 存储 列 ， 就 像 
图 16-1 展 示 的 那样 。 相 反 ， 数 据 是 按照 一 列 一 列 来 存储 的 ， 结 果 就 是 ， 来 自 同 一 行 的 列 可 能 会 存储 在 
不 同 的 块 中 。 此 外 ， 为 尽 可 能 多 地 将 相同 类 型 的 数据 存储 在 一 起 ， 基 础 的 存储 结构 ， 称 之 为 逻辑 压缩 
单元 (logical compression unit )， 由 多 个 块 组 成 。 一 列 一 列 的 存储 数据 以 及 使 用 更 大 的 存储 结构 都 是 为 
了 实现 更 高 的 压缩 比 。 然 而 ， 当 处 理 压 缩 的 数据 时 ， 更 高 的 压缩 比 通常 会 关联 更 高 的 CPU 消耗 。 出 于 
这 个 原因 ， 可 以 在 四 个 压缩 级 别 之 间 选 择 ( 这 里 是 根据 预期 的 压缩 比 和 CPU 消耗 排序 的 ): QUERY LOW、 
QUERY HIGH 、ARCHIVE LOW 以 及 ARCHIVE HIGH。 注 意 在 Exadata 系 统 上 ， 可 以 减轻 解压 缩 的 负载 ( 但 是 需 
要 智能 扫描 )， 而 压缩 通常 是 由 数据 库 实例 执行 的 。 混 合 列 压 缩 的 其 他 次 端 如 下 所 示 。 

口 只 有 当 数 据 是 通过 直接 路 径 接口 加 载 的 时 候 才 会 被 压缩 ( 与 基础 表 压 缩 的 要 求 一 样 ); 正常 的 

INSERT 语 句 将 数据 存储 在 使 用 高 级 行 压缩 的 块 中 。 
口 在 12.1.0.1 版 本 以 前 ( 包括 12.1.0.1 版 本 )， 不 支持 行 级 别 锁定 ; 自 12.1.0.2 版 本 起 ， 可 控制 行 级 
别 锁定 的 使 用 ( 默认 是 不 使 用 )。 当 不 使 用 行 级 别 锁 定时 ， 仅 可 以 锁定 整个 逻辑 压缩 单元 。 

口 即使 在 表 级 别 没有 显 式 启 用 行 移动 ，UPDATE 请 句 还 是 会 导致 行 移动 ， 因 此 ,rowid 会 发 生变 化 。 

概括 起 来 ,我 建议 只 在 与 基础 表 压 缩 相同 的 情况 下 使 用 混合 列 压 缩 。 唯一 的 额外 要 求 是 你 需要 一 
个 表 16-2 中 列 出 的 存储 子 系统 。 

需要 注意 的 是 , 正如 表 16-3 所 示 , 在 11.1 和 12.1 之 间 的 每 个 版 本 都 更 改 了 用 于 激活 某 一 具体 数据 压 
缩 方法 的 关键 字 。 同 时 还 有 ， 每 个 新 版 本 都 不 壮 成 之 前 版 本 使 用 的 关键 字 。 在 所 有 版 本 中 都 以 相同 方 
式 发 挥 作用 的 关键 字 只 有 以 下 两 个 : 


口 NOCOMPRESS 禁 用 表 压 缩 
口 COMPRESS 启 用 基础 表 压 缩 


表 16-3 不同 的 版 本 支持 的 不 同 表 压 缩 子 名 


基础 表 压 缩 


COMPRESS FOR 
DIRECT LOAD 
OPERATIONS 


COMPRESS BASIC 


ROW STORE COMPRESS 
BASIC 
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高 级 行 压缩 混合 列 压缩 
COMPRESS FOR ALL / 
OPERATIONS 
COMPRESS FOR OLTP COMPRESS FOR [QUERYIARCHIVE] 
[LOWIHIGH] 


ROW STORE COMPRESS COLUMN STORE COMPRESS FOR 
ADVANCED [QUERYIARCHIVE] [LOWIHIGH] 
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“互联 网 上 充斥 着 大 量 的 Oracle 性 能 相关 信息 ， 不 但 高 度 碎片 化 ， 而 且 有 很 多 是 错误 的 。 本 书 则 异常 清晰 地 
给 出 了 Oracle 性 能 相关 的 理论 和 实践 ， 明 确 指导 读者 找到 需要 达成 的 目的 以 及 如 何 达成 目的 。” 


“这 是 一 本 技术 与 理念 并 重 的 参考 书 ， 不 仅 包 含 了 大 量 完备 的 可 重用 的 实例 ， 而 且 包 含 了 一 些 富有 说 服 力 的 
新 观点 。 我 可 以 用 他 的 观点 去 说 服 更 多 的 人 做 正确 的 事 。” 


前 端 业务 应 用 炙手可热 之 日 ， 便 是 优化 后 端 数据 库 性 能 之 时 。 当 此 之 际 ， 身 怀 数 据 库 优化 绝技 ， 可 以 让 你 平 
步 职 场 ， 傲 视 群 英 。 

本 书 是 Oracle 数 据 库 优 化 专家 Christian Antognini 的 一 部 继往开来 的 里 程 碑 式 著作 。 书 中 的 最 佳 实践 和 诸多 
建议 全 部 来 源 于 作者 在 实战 一 线 的 丰富 积累 ， 不 仅 简单 实用 ， 而 且 发 人 深 省 ， 堪 称 一 座 “ 宝 库 ”， 适 合 各 层次 读 
者 研读 和 发 掘 。 

与 其 他 同类 图 书 不 同 ， 本 书 不 仅 涵盖 了 当前 可 用 的 各 种 Oracle 版 本 ， 还 指明 了 各 个 版 本 独 有 的 性 能 优化 特 
性 。 全 书 以 疡 新 的 视角 开篇 立论 ， 围 绕 查 明 问 题 真相 和 搜寻 有 效 方略 ， 透 彻 讲解 了 查询 优化 器 的 配置 ， 表 访问 、 
连接 和 物理 表 布 局 的 优化 ， 以 及 加 速 SQL 执行 计划 等 重要 主题 ， 被 读者 誉 为 “最 透彻 ， 但 又 最 通俗 的 性 能 优化 
好 书 ” - 

与 本 书 第 一 版 相 比 ， 作 者 增加 了 关于 Oracle Database 119 和 Oracle Database 12c 的 内 容 , 补充 了 层次 剖 
析 工 具 、ASH、AWR 和 Statspack 等 知识 点 ， 并 根据 可 读 性 重新 组 织 了 部 分 素材 。 
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